Archive for the ‘Draft Specs’ Category

Sunday, May 7th, 2017

Web Authentication Working Draft rev 5 (WD-05) is officially published here: https://www.w3.org/TR/2017/WD-webauthn-20170505/

The latest official WebAuthn spec release is always available here: https://www.w3.org/TR/webauthn/

Please note that this spec is only a Working DRAFT and will change, possibly in “breaking” ways. While not a candidate recommendation, this version is informally intended by the working group to be an Implementer’s Draft, which will be used for experimenting with implementations of the API.

WebAuthn WD-05 features many significant changes from the prior version:
* Alignment with Credential Management (CredMan): https://w3c.github.io/webappsec-credential-management/
* Using the term Public Key Credentials rather than Scoped Credentials
* Algorithms updated to more precisely define their operations and to be CredMan compatible
* Expanded and more explicit specification of the extensions framework
* Terminology expansion and polishing
* and more…

HTML “inline” Diff: http://www.kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-dda3e24-WD-05–from–index-master-tr-ce7925c-WD-04.html

PDF side-by-side text-only Diff: http://kingsmountain.com/doc/diff/diff-webauthn-index-master-tr-dda3e24-WD-05–from–index-master-tr-ce7925c-WD-04.pdf

Wd-05 Release Page at github: https://github.com/w3c/webauthn/releases/tag/WD-05-20170505

Average Rating: 4.6 out of 5 based on 195 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, Protocols, Web Security | No Comments »

Tuesday, October 2nd, 2012

As I’d noted back in July, the draft HSTS spec was in IETF-wide last call, from which we exited in August with various helpful comments. We applied summore elbow grease to the ol’spec and shipped it to the IESG (Internet Engineering Steering Group) for further inspection, received more good comments, subsequently applied more tweaks and polish, and voila(!), this morning we have this little missive in our email…

[websec] Protocol Action: ‘HTTP Strict Transport Security (HSTS)’ to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)

At this point, the draft HSTS spec will be placed on the RFC Editor’s queue (which is fairly large & diverse) and will emerge in several weeks as an RFC with a proper RFC number and all.

Many thanks to all who’ve contributed, especially to Collin Jackson & Adam Barth for originally inventing this approach (which they dubbed “ForceHTTPS“).

=JeffH

PS: The Wikipedia HSTS entry has a consolidated specification history as well as information regarding implementation and deployment.

Average Rating: 4.5 out of 5 based on 271 user reviews.

[ | | | from fda approved pharmacy | ]

Tags:, , , ,
Posted in Draft Specs, IETF, Protocols, Security, Web Security | No Comments »

Tuesday, November 4th, 2008

There’s a new revision of the SIP-SAML profile spec..

SIP SAML Profile and Binding
http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-05.txt

The key changes in this revision are that we’re aiming for experimental track (for now) due to a subtle-but-important impedance mismatch with the “SIP Identity” spec (RFC 4474, which we build upon), and we’ve add an additional profile to the spec. This new profile simply specifies SAML assertion conveyance “by value” in the body of SIP message(s) rather than “by reference”.

Note that the overall notion of “SIP Identity” has been in-flux over the last year+. Once that set of issues is (hopefully) resolved, then we can do another SIP-SAML spec on the standards track.

Also, the SIP WG co-chairs have called for Working Group Last Call on this -05 revision.

=JeffH sez getcher comments in!

Average Rating: 5 out of 5 based on 263 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, Identity, IETF, SAML, SIP, VoIP | 1 Comment »

Friday, September 21st, 2007

I’ve updated the SAML-lSSO and SAML OpenID Profile specs just to bring them up-to-date with the latest revisions of various SAML and OpenID specs and to fix minor editorial issues. The SAML-lSSO spec is presently not a current IETF Internet-Draft — it’s prior version expired a few months ago. We’re thinking about whether we want to pursue that spec “officially” or not. The issue with it being that in implementing it, one can optionally turn security completely off — which is a “feature” various folks advocating for so-called “open Internet” identity management desire. But SDOs such as IETF, OASIS, W3C, Liberty Alliance, etc all would look askance at blessing such a spec. In fact the IETF definitely would not allow it to go forward in that they have an explicit policy against promulgating insecure protocols.

The SAML OpenID Profile is a simple hack I threw together a year or so ago (in a single afternoon) to prove the point that there’s nothing OpenID accomplishes protocol- and user-experience-wise that is inherently un-do-able with SAML. [1]

Anyway, here’s the links to said specs…

SAMLv2 Lightweight Web Browser SSO Profile

OpenID-SAML Lightweight Web Browser SSO Profile – Draft 02

=JeffH sez check ’em out.

[1] Note that I’m not claiming that they are equivalently “easy” to implement. By “implement” I mean to write code implementing the protocol on both or either the Relying Party or Identity Provider (aka OpenID Provider) side. Also note that I don’t use the term “implemneting” as a synonym for “deployment”. Also, I am not claiming that they are equivalently “easy” to deploy. Almost all the artifacts of deployment are inherent in how a protocol is implemented. A “feature” that’s often claimed about OpenID as a differentiator is that anyone with a minimally capable hosting environment can field an OpenID relying party. I.e. they don’t need root access, nor access to their webserver configuration, etc. In fact, the same is true with some (all?) of the “scripty” SAML implementations, e.g. ZXID being a case in point.

Average Rating: 4.4 out of 5 based on 187 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, Identity, SAML | No Comments »

Friday, February 2nd, 2007

The latest revision of the SAML HTTP POST-SimpleSign Binding Spec is here…

draft-sstc-saml-binding-simplesign-02
http://www.oasis-open.org/committees/download.php
/21715/draft-sstc-saml-binding-simplesign-02.pdf

Diff version: draft-sstc-saml-binding-simplesign-02-diff
http://www.oasis-open.org/committees/download.php
/21716/draft-sstc-saml-binding-simplesign-02-diff.pdf

The salient difference between this new rev of this spec and the prior rev (which is at “Committee Draft” maturity level and out for Public Review) is that now we sign the SAML protocol message’s raw XML representation, rather than base64 encoding it first (as we specified in the previous revs of this spec). The reason for this change is..

Experimentation shows that many web browsers alter linefeeds when submitting form controls that span multiple lines. Since base64-encoded data often wraps, it is not possible to guarantee that the values submitted will match what the original signer produced, resulting in verification failures. Using the raw XML content as a component of the octet string addresses this issue.

..which is a direct quote from the new spec revision (at line 205).

JeffH sez check it out.

Average Rating: 4.8 out of 5 based on 164 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, SAML | No Comments »

Thursday, October 26th, 2006

Scott and I have updated the SAML-LSSO (Lightweight Web Browser Single-SignOn) profile and SimpleSign binding specs. Together they specify a lightweight SAML profile whose “security knob” can be dialed from completely “Off” to “On” (to various degrees) at implementation and/or deployment time. And if security is “On”, then the SimpleSign technique can be used, and/or the XMLdsig-based technique. The difference between the SimpleSign binding and the original SAMLv2 HTTP POST binding is rather small, and SimpleSign doesn’t obviate any aspects of the other binding, thus present implementations can be easily enhanced to support both bindings with minimal fuss.

Thus we feel one can easily, with SAML, provide the spectrum of simple-no-security-to-simple-but-with-security “Single Sign-On” functionality that various parties are currently running around attempting to reinvent.

The specs are here…

SAMLv2 Lightweight Web Browser SSO Profile

SAMLv2: HTTP POST “SimpleSign” Binding

JeffH sez check ’em out.

Average Rating: 4.8 out of 5 based on 210 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, SAML | 1 Comment »

Wednesday, October 4th, 2006

Scott Cantor and I have updated the SAML HTTP POST-SimpleSign binding, which I’d posted about earlier in September.

The revised spec is here: draft-hodges-saml-binding-simplesign-02.pdf.

We enhanced section “1.2.4 Message Encoding and Conveyance” to allow for conveyance of a signed (via XMLdsig) SAML message via this binding. The primary implication of this change is that the only material difference between this binding and the “stock” HTTP POST binding in saml-bindings-2.0-os is inclusion of HTTP POST-SimpleSign’s particular sign-the-BLOB signature. We hope that this leads to greater code-reuse and ease for implementors.

We’re thinking we’re getting pretty close to being “done” with this particular spec.

Also, I need to update the SAMLv2 Lightweight Web Browser SSO Profile Internet-Draft (draft-hodges-saml-lsso-00.txt) to reference this new rev of the HTTP POST-SimpleSign binding.

Average Rating: 4.6 out of 5 based on 233 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, SAML | No Comments »

Friday, September 8th, 2006

Scott Cantor and I have revised the SAML HTTP POST-NoXMLdsig binding, which I’d posted about a while back.

We’ve renamed the binding to: “HTTP POST-SimpleSign”

The revised spec is here: draft-hodges-saml-binding-simplesign-01.pdf.

Note that the new “SimpleSign” spec obsoletes the old “NoXMLdsig” one.

There’s also various other relatively minor (some are subtle-but-important) changes and fixes, such as..

  • Clarified that conveyed assertions may be signed.
  • Added optional conveyance of KeyInfo from XMLdsig in order to supply a hint wrt keying material to the recipient.
  • Clarified composability with other SAML HTTP-based bindings.
  • Revamped illustration.
  • etc.

We’re thinking we’re getting pretty close to being “done” with this particular spec.

FYI, an example SAML profile utilizing this binding is..

SAMLv2 Lightweight Web Browser SSO Profile
draft-hodges-saml-lsso-00.txt

Average Rating: 4.6 out of 5 based on 156 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, SAML | No Comments »

Tuesday, June 13th, 2006

From various discussions held with various folks, e.g. on the IDWorkshop mailing list (aka “Identity Gang“), it has become apparent that the major sticking point w.r.t. SAMLv2 adoption in some quarters, e.g. in the “scripting” world (e.g. PHP/Perl/Python/Ruby), is the present SAMLv2 bindings‘ mandated reliance on XML Digital Signature (aka “XMLdsig”, http://www.w3.org/TR/xmldsig-core/). Interoperable XMLdsig libraries are hard to come by, perhaps due to the XMLdsig spec’s complexity and reliance on “XML canonicalization” (aka “c14n”, http://www.w3.org/TR/xml-c14n) which is inherently complex on it’s own.

So Scott Cantor and I have hacked up this draft alternative SAMLv2 HTTP POST “NoXMLdsig” binding..

SAMLv2 HTTP POST “NoXMLdsig” binding

Now the next step will be to craft a SAMLv2 Profile that takes advantage of it.

Average Rating: 5 out of 5 based on 230 user reviews.

[ | | | from fda approved pharmacy | ]

Posted in Draft Specs, Identity, SAML, Security | 1 Comment »