The JSON Web Key (JWK) Thumbprint draft has been updated to incorporate feedback received from Jim Schaad, including defining the JWK Thumbprint computation in a manner that allows different hash functions to be used over time. The specification is available at:
An HTML formatted version is also available at:
All of these 9 drafts have now been approved and sent to the RFC Editor:
That means that their content is now completely stable and they’ll soon become Internet standards — RFCs. Thanks for all of your contributions in creating, reviewing, and most importantly, using these specifications. Special thanks go to the other spec editors Nat Sakimura, John Bradley, Joe Hildebrand, Brian Campbell, Chuck Mortimore, Matt Miller, and Yaron Goland.
New versions of the JSON Web Signature (JWS) and JSON Web Key (JWK) drafts have been submitted that address a few more IESG comments that were identified by our area director Kathleen Moriarty during her final review of the documents. Thanks to Richard Barnes for working on wording to address his comment on security considerations for binding attributes to JWKs. See the Document History sections for descriptions of the edits, none of which resulted in data structure changes.
The plan is for these documents to be forwarded to the RFC editor. The other related documents have already been approved.
The specifications are available at:
HTML formatted versions are available at:
The document shepherd Karen O’Donoghue and I completed a review of all the IESG comments in the IETF data tracker today in preparation for the drafts going to the RFC Editor. This set of drafts addresses all the remaining comments that we thought should be dealt with in the final documents. The only changes were:
Unless additional issues are identified soon, these should be the drafts that go to the RFC Editor.
The specifications are available at:
HTML formatted versions are available at:
These drafts incorporate this additional registry field in the JSON Web Signature and Encryption Algorithms registry, based on a comment by Stephen Farrell, with input from Jim Schaad and Kathleen Moriarty:
Algorithm Analysis Documents(s):
References to publication(s) in well-known cryptographic conferences, by national standards bodies, or by other authoritative sources analyzing the cryptographic soundness of the algorithm to be registered. The designated experts may require convincing evidence of the cryptographic soundness of a new algorithm to be provided with the registration request unless the algorithm is being registered as Deprecated or Prohibited. Having gone through working group and IETF review, the initial registrations made by this document are exempt from the need to provide this information.
This addition is in the document:
An HTML formatted version is also available at:
Slightly updated JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) drafts have been published that address the last of the IESG review comments, which were follow-up comments by Stephen Farrell and Pete Resnick. All DISCUSS comments had already been addressed by the previous drafts. The one normative change is that implementations must now discard RSA private keys with an “oth” parameter when the implementation does not support private keys with more than two primes. The remaining changes were editorial improvements suggested by Pete.
The specifications are available at:
HTML formatted versions are available at:
My article A JSON-Based Identity Protocol Suite has been published in the Fall 2014 issue of Information Standards Quarterly, with this citation page. This issue on Identity Management was guest-edited by Andy Dale. The article’s abstract is:
Achieving interoperable digital identity systems requires agreement on data representations and protocols among the participants. While there are several suites of successful interoperable identity data representations and protocols, including Kerberos, X.509, SAML 2.0, WS-*, and OpenID 2.0, they have used data representations that have limited or no support in browsers, mobile devices, and modern Web development environments, such as ASN.1, XML, or custom data representations. A new set of open digital identity standards have emerged that utilize JSON data representations and simple REST-based communication patterns. These protocols and data formats are intentionally designed to be easy to use in browsers, mobile devices, and modern Web development environments, which typically include native JSON support. This paper surveys a number of these open JSON-based digital identity protocols and discusses how they are being used to provide practical interoperable digital identity solutions.
This article is actually a follow-on progress report to my April 2011 position paper The Emerging JSON-Based Identity Protocol Suite. While standards can seem to progress slowly at times, comparing the two makes clear just how much has been accomplished in this time and shows that what was a prediction in 2011 is now a reality in widespread use.
These JOSE and JWT drafts contain updates intended to address the remaining outstanding IESG review comments by Pete Resnick, Stephen Farrell, and Richard Barnes, other than one that Pete may still provide text for. Algorithm names are now restricted to using only ASCII characters, the TLS requirements language has been refined, the language about integrity protecting header parameters used in trust decisions has been augmented, we now say what to do when an RSA private key with “oth” is encountered but not supported, and we now talk about JWSs with invalid signatures being considered invalid, rather than them being rejected. Also, added the CRT parameter values to example JWK RSA private key representations.
The specifications are available at:
HTML formatted versions are available at:
The JSON Web Key (JWK) Thumbprint specification was adopted by the JOSE working group during IETF 91. The initial working group version is identical to the individual submission version incorporating feedback from IETF 90, other than the dates and document identifier.
JWK Thumbprints are used by the recently approved OpenID Connect Core 1.0 incorporating errata set 1 spec. JOSE working group co-chair Jim Schaad said during the working group meeting that he would move the document along fast.
The specification is available at:
An HTML formatted version is also available at:
These JOSE and JWT drafts incorporate resolutions to some previously unresolved IESG comments. The primary change was adding flattened JSON Serialization syntax for the single digital signature/MAC and single recipient cases. See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#appendix-A.7 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-A.5 for examples. See the history entries for details on the few other changes. No breaking changes were made.
The specifications are available at:
HTML formatted versions are available at:
I’ve posted updated JOSE and JWT drafts that address the Applications Area Directorate review comments. Thanks to Ray Polk and Carsten Bormann for their useful reviews. No breaking changes were made.
The specifications are available at:
HTML formatted versions are available at:
Updated JOSE and JWT specifications have been published that address the IESG review comments received. The one set of normative changes was to change the implementation requirements for RSAES-PKCS1-V1_5 from Required to Recommended- and for RSA-OAEP from Optional to Recommended+. Thanks to Richard Barnes, Alissa Cooper, Stephen Farrell, Brian Haberman, Ted Lemon, Barry Leiba, and Pete Resnick for their IESG review comments, plus thanks to Scott Brim and Russ Housley for additional Gen-ART review comments, and thanks to the working group members who helped respond to them. Many valuable clarifications resulted from your thorough reviews.
The specifications are available at:
HTML formatted versions are available at:
Updated JOSE and JWT drafts have been published that address JSON Web Key (JWK) secdir review comments by Stephen Kent that were inadvertently not addressed in the previous versions. Most of the changes were to the JWK draft. A few changes also had to be made across the other drafts to keep them in sync. I also added acknowledgements to several additional contributors. No breaking changes were made.
The specifications are available at:
Differences since the previous drafts can be viewed at:
HTML formatted versions are available at:
New versions of the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specifications have been published incorporating feedback received in IETF Last Call comments. Thanks to Russ Housley and Roni Even for their Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie Kaufman, and Warren Kumari for their secdir reviews, to Tom Yu for his individual review, and to James Manger and Chuck Mortimore who provided feedback based on deployment experiences, as well as to the many JOSE and OAuth working group members who pitched in to discuss resolutions. Many clarifications resulted. No breaking changes were made.
The specifications are available at:
HTML formatted versions are available at:
There’s now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Here’s a summary of the two concepts in a nutshell: Act-As indicates that the requestor wants a token that contains claims about two distinct entities: the requestor and an external entity represented by the token in the act_as parameter. On-Behalf-Of indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the on_behalf_of parameter.
This draft is identical to the previously announced token exchange draft, other than that is a working group document, rather than an individual submission.
This specification is available at:
An HTML formatted version is also available at:
My submission to the W3C Workshop on Authentication, Hardware Tokens and Beyond was accepted for presentation. I’ll be discussing The Increasing Importance of Proof-of-Possession to the Web. The abstract of my position paper is:
A number of different initiatives and organizations are now defining new ways to use proof-of-possession in several kinds of Web protocols. These range from cookies that can’t be stolen and reused, identity assertions only usable by a particular party, password-less login, to proof of eligibility to participate. While each of these developments is important in isolation, the pattern of all of them concurrently emerging now demonstrates the increasing importance of proof-of-possession to the Web.
It should be a quick and hopefully worthwhile read. I’m looking forward to discussing it with many of you at the workshop!
An updated OAuth Dynamic Client Registration spec has been published that finished applying clarifications requested during working group last call (WGLC). The proposed changes were discussed during the OAuth working group meeting at IETF 90 in Toronto. See the History section for details on the changes made.
The OAuth Dynamic Client Registration Management was also updated to change it from being Standards Track to Experimental.
The updated specifications are available at:
HTML formatted versions are also available at:
Brian Campbell updated the OAuth Assertions specifications to add Privacy Considerations sections, responding to area director feedback. Thanks, Brian!
The specifications are available at:
HTML formatted versions are also available at:
I’ve updated the JSON Web Key (JWK) Thumbprint specification to incorporate the JOSE working group feedback on the -00 draft from IETF 90. The two changes were:
If a canonical JSON representation standard is ever adopted, this specification could be revised to use it, resulting in unambiguous definitions for those values (which are unlikely to ever occur in JWKs) as well. (Defining a complete canonical JSON representation is very much out of scope for this work!)
The specification is available at:
An HTML formatted version is also available at:
In preparation for IETF 90 in Toronto, I’ve updated the JWT Proof-of-Possession specification. The changes are mostly editorial in nature, plus a few changes that hadn’t received adequate review prior to inclusion in the -01 draft were reverted.
This specification is available at:
An HTML formatted version is also available at:
Powered by WordPress & Theme by Anders Norén