Musings on Digital Identity

Category: Claims Page 10 of 13

First Release Candidates for final OpenID Connect specifications

OpenID logoI’m pleased to announce that the first release candidate versions for final OpenID Connect specifications have been published. The complete set of specifications has been updated to resolve all issues that had been filed against the specs being finished.

Please review these this week, in time for the in-person working group meeting on Monday. Besides publishing the specs in the usual formats, I’ve also created a Word version of the core spec with tracked changes turned on to facilitate people marking it up with specific proposed text changes. If you’re in the working group, please download it and make any corrections or changes you’d like to propose for the final specification.

The release candidate spec versions are:

Also, two implementer’s guides are also available to serve as self-contained references for implementers of basic Web-based Relying Parties:

Thanks to Nat Sakimura for the early feedback. The structure of Core has been changed somewhat since -13 to adopt some of his suggestions.

OpenID Connect Specs Nearing Completion

OpenID logoBased on feedback from developers, the OpenID Connect working group decided to replace the OpenID Connect Messages and OpenID Connect Standard specifications with a new OpenID Connect Core specification that combines the contents from both of them before finishing OpenID Connect. The content has also been restructured to separate Authentication from other features such as Claims and to have separate Authentication sections for the different OAuth 2.0 flows. No changes to the protocol were made. The publication of this new spec is another major step towards finishing OpenID Connect.

Please review this and the other OpenID Connect specifications in the coming week. While a few local changes will still be made this week to address issues that have been identified since the approval of the Implementer’s Drafts, I fully expect that the working group will decide at the in-person working group meeting just over a week from now that it’s time to publish proposed final specifications.

Thanks to Nat Sakimura for producing a proof-of-concept document restructuring that the structure of the current OpenID Connect Core spec is based upon. And thanks to Torsten Lodderstedt for convincing us that the specs will be clearer by better separating the descriptions of logically distinct features while combining previously separate descriptions of highly interrelated functionality.

JOSE -17 and JWT -12 drafts reducing duplicated text

IETF logoJSON Object Signing and Encryption (JOSE) -17 and JSON Web Token (JWT) -12 drafts have been published with editorial changes that reduce duplicated text between the JOSE specs. Also, the “typ” and “cty” header parameters were revised to always refer to media type values. The text about which serializations are mandatory to implement was updated. Finally, thanks to Matt Miller for supplying an encryption example using PBES2.

See the Document History appendices for more details on the changes made and issues addressed.

The drafts are available at:

HTML formatted versions are also available at:

Second OpenID Connect Implementer’s Drafts Approved

OpenID logoThe OpenID Foundation members have voted to approve a second set of OpenID Connect Implementer’s Drafts. The working group intends for the final specifications to be compatible with these Implementer’s Drafts.

Implementer’s Drafts are stable versions of specifications intended for trial implementations and deployments that provide specific IPR protections to those using them. Implementers and deployers are encouraged to continue providing feedback to the working group on these specifications based upon their experiences using them.

JOSE -14 and JWT -11 drafts with additional algorithms and examples published

IETF logoJSON Object Signing and Encryption (JOSE) -14 drafts have been published that incorporate minor updates requested by the working group since the last working group call. The primary change was adding algorithm identifiers for AES algorithms using 192 bit keys; supporting these algorithms is optional. The only breaking changes were to the password-based encryption algorithm parameter representation. This version adds an example ECDH-ES Key Agreement computation.

The JSON Web Token (JWT) -11 draft adds a Nested JWT example — in which the claims are first signed, and then encrypted.

The drafts are available at:

HTML formatted versions are also available at:

OAuth assertions drafts improving interop characteristics

IETF logoUpdated OAuth assertions drafts have been posted that improve their interoperability characteristics in a manner suggested during IESG review: they now state that issuer and audience values should be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 unless otherwise specified by the application.

The drafts are available at:

HTML formatted versions are available at:

JWT draft -10

IETF logoJSON Web Token (JWT) draft -10 allows Claims to be replicated as Header Parameters in encrypted JWTs as needed by applications that require an unencrypted representation of specific Claims. This draft is available at http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-10, with an HTML formatted version also available at https://self-issued.info/docs/draft-ietf-oauth-json-web-token-10.html.

JOSE -12 and JWT -09 drafts released

IETF logoThe -12 JSON Object Signing and Encryption (JOSE) drafts have been released incorporating issue resolutions agreed to on the July 1, 2013 working group call and on the mailing list. Most of the changes were editorial improvements suggested by Jim Schaad and Richard Barnes. Changes included clarifying that the “typ” and “cty” header parameters are for use by applications and don’t affect JOSE processing, replacing the MIME types application/jws, application/jwe, application/jws+json, and application/jwe+json with application/jose and application/jose+json, and relaxing language on JSON parsing when duplicate member names are encountered to allow use of ECMAScript JSON parsers. See the history entries for the full set of changes.

Corresponding changes to the JSON Web Token (JWT) spec were also published in draft -09.

The drafts are available at:

HTML formatted versions are also available at:

Production Release of Microsoft JWT Support

Microsoft has released production support for the JSON Web Token (JWT). Read about it in Alex Simons’ release announcement and Vittorio Bertocci’s blog post on the JWT support.

Proposed Second OpenID Connect Implementer’s Drafts Published

OpenID logoToday marks another significant milestone towards completing the OpenID Connect standard. The OpenID Foundation has announced that the 45 day review period for the second set of proposed Implementer’s Drafts has begun. The working group believes that these are stable and complete drafts. They are being proposed as Implementer’s Drafts, rather than Final Specifications at this time, because of the dependencies on some IETF specifications that are still undergoing standardization — primarily the JSON Web Token (JWT) specification and the JSON Object Signing and Encryption (JOSE) specifications underlying it.

An Implementer’s Draft is a stable version of a specification intended for implementation and deployment that provides intellectual property protections to implementers of the specification. These updated drafts are the product of incorporating months of feedback from implementers and reviewers on earlier specification drafts, starting with the previous Implementer’s Drafts, including feedback resulting from several rounds of interop testing. Thanks to all of you who have been working towards the completion of OpenID Connect!

These specifications are available at:

JOSE -11 drafts and JWT -08 released

IETF logoThe -11 drafts of the JSON Object Signing and Encryption (JOSE) specifications have been released that incorporate the changes agreed to at the interim working group meeting last month. Most of the changes were to the JWS and JWE JSON Serialization representations, enabling more flexible treatment of header parameter values. Other changes included removing the Encrypted Key value from the JWE integrity calculation, saying more about key identification, adding key identification parameters to some of the examples, clarifying the use of “kid” values in JWK Sets, enabling X.509 key representations in JWKs, recommending protecting JWKs containing non-public information by encrypting them with JWE, adding “alg” values for RSASSA-PSS, registering additional MIME types, and a number of clarifications. A corresponding -08 JSON Web Token (JWT) spec was also released that updated the encrypted JWT example value to track the JWE change. Hopefully this will be the last breaking change to the encryption calculations.

The specifications are available at:

HTML formatted versions are available at:

Fourth Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoA fourth set of release candidates for the upcoming OpenID Connect Implementer’s Drafts has been released. Changes since the third release candidates mostly consist of editorial improvements. There were only two changes that will result in changes to implementations. The first was replacing the “updated_time” claim, which used a textual date format, with the “updated_at” claim, which uses the same numeric representation as the other OpenID Connect date/time claims. The second was replacing the “PKIX” JWK key type with the “x5c” JWK key member (a change actually made this week by the JOSE working group).

These are ready for discussion at Monday’s in-person OpenID Connect working group meeting. All issues filed have been addressed.

The updated specifications are:

These specifications did not change:

Thanks to all who continued reviewing and implementing the specifications, resulting in the improvements contained in this release. I’ll look forward to seeing many of you on Monday!

JOSE and JWT specs incorporating decisions from IETF 86

IETF logoNew versions of the JSON Object Signing and Encryption (JOSE) specifications JSON Web Signature (JWS), JSON Web Encryption (JWE), JSON Web Key (JWK), and JSON Web Algorithms (JWA) and the JSON Web Token (JWT) specification have been released that incorporate the working group decisions made during and since IETF 86.

The primary new features in these working group drafts are:

  • adding support for private and symmetric keys to JWK and JWA,
  • adding support for JSON Serializations to JWS and JWE,
  • replacing the custom JOSE CBC+HMAC algorithms with ones compatible with those proposed in draft-mcgrew-aead-aes-cbc-hmac-sha2,
  • defining that the default action for header parameters and claims that are not understood is to ignore them, while providing a way to designate that some extension header parameters must be understood.

More details on the changes made can be found in the Document History entries.

The specifications are available at:

HTML formatted versions are also available at:

Tim Bray on ID Tokens

OpenID logoTim Bray has written a post giving his take on what ID Tokens are and why they’re valuable, both for OpenID Connect and beyond. Full of geeky identity goodness…

Updated OAuth Assertions Drafts Published

OAuth logoThanks to Brian Campbell for publishing updated versions of all three OAuth Assertions specifications. These drafts address comments and “discuss” issues from the IESG review of the Assertion Framework specification as well as issues that arose in subsequent discussions and decisions made during IETF 86 in Orlando. Brian did the bulk of the heavy lifting and I added some editorial work at the end of the process.

The documents now have new titles to make the scope of these specifications more explicit. The new titles and links to the documents are:

Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants

JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

See http://www.ietf.org/mail-archive/web/oauth/current/msg11213.html or the document History entries for more details on the changes made.

HTML formatted versions are also available at:

Third Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoA third set of Release Candidates for the pending OpenID Connect Implementer’s Drafts have been released. Like the first set, the second set of Release Candidates, which were published earlier this month, also received thorough review, resulting in a smaller set of additional refinements. The changes primarily made some the claim definitions more precise and provided more guidance on support for multiple languages and scripts.

Were it not for a set of pending changes about to be made to the JSON Object Signing and Encryption (JOSE) specifications, this set of specifications would likely actually be the Implementer’s Drafts. However, the OpenID Connect working group made the decision to have those (non-breaking) JOSE changes be applied before we declare that the Implementer’s Drafts are done. Expect announcements about both the JOSE updates and the OpenID Connect Implementer’s Drafts soon.

The new specifications are:

See the History entries in the specs for more details on the changes made.

Thanks again to all who reviewed and implemented the recent drafts!

The Emerging JSON/REST-Based Identity Protocol Suite

IETF logo Last week at the Japan Identity and Cloud Symposium I gave a presentation on this topic: A new set of simple, open identity protocols is emerging that utilize JSON data representations and REST-based communication patterns, including OAuth, JSON Web Token (JWT), JSON Object Signing and Encryption (JOSE), and WebFinger. I’ve posted PowerPoint and PDF versions of the presentation.

Thanks again to the organizers of JICS 2013 for a great event!

Second Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoI’m pleased to announce that a second set of Release Candidates for the upcoming OpenID Connect Implementer’s Drafts have been released. The first set of Release Candidates received thorough review, resulting in quite a bit of detailed feedback. The current specs incorporate the feedback received, making them simpler, more consistent, and easier to understand.

Please review these this week — especially if you had submitted feedback. The working group plans to decide whether we’re ready to declare Implementer’s Drafts during the OpenID Meeting before IETF 86 on Sunday.

The new specifications are:

See the History entries in the specs for details on the changes made.

Thanks again to all who did so much to get us to this point, including the spec writers, working group members, and especially the implementers!

Release Candidates for OpenID Connect Implementer’s Drafts

OpenID logoI’m pleased to announce that release candidate versions of the soon-to-come OpenID Connect Implementer’s Drafts have been released. All the anticipated breaking changes to the protocol are now in place, including switching Discovery over from using Simple Web Discovery to WebFinger and aligning Registration with the OAuth Dynamic Client Registration draft. While several names changed for consistency reasons, the changes to Discovery and Registration were the only architectural changes.

Please thoroughly review these drafts this week and report any issues that you believe need to be addressed before we release the Implementer’s Draft versions.

Normative changes since the December 27th, 2012 release were:

  • Use WebFinger for OpenID Provider discovery instead of Simple Web Discovery. This also means that account identifiers using e-mail address syntax are prefixed by the acct: scheme when passed to WebFinger.
  • Aligned Registration parameters with OAuth Dynamic Registration draft.
  • Added Implementation Considerations sections to all specifications, which specify which features are mandatory to implement.
  • Removed requirement that the “c_hash” and “at_hash” be computed using SHA-2 algorithms (for crypto agility reasons).
  • Refined aspects of using encrypted ID Tokens.
  • Finished specifying elements of key management for self-issued OPs.
  • Added “display_values_supported“, “claim_types_supported“, “claims_supported“, and “service_documentation” discovery elements.
  • Defined REQUIRED, RECOMMENDED, and OPTIONAL discovery elements.
  • Refined Session Management specification, including descriptions of OP and RP iframe behaviors.
  • Deleted “javascript_origin_uris“, which is no longer present in Session Management.
  • Added new “session_state” parameter to the authorization response for Session Management.
  • Added new “post_logout_redirect_url” registration parameter for Session Management.

Also, renamed these identifiers for naming consistency reasons:

  • user_jwk -> sub_jwk (used in self-issued ID Tokens)
  • token_endpoint_auth_type -> token_endpoint_auth_method
  • token_endpoint_auth_types_supported -> token_endpoint_auth_methods_supported
  • check_session_iframe_url -> check_session_iframe
  • end_session_endpoint_url -> end_session_endpoint
  • type -> operation (in Registration)
  • associate -> register (in Registration)
  • application_name -> client_name
  • check_session_endpoint -> check_session_iframe

See the History entries in the specifications for more details.

The new specification versions are at:

Thanks to all who did so much to get us to this point, including the spec writers, working group members, and implementers!

OAuth Assertion Framework draft -10

OAuth logoDraft 10 of the Assertion Framework for OAuth 2.0 has been published. It contains non-normative changes that add the “Interoperability Considerations” section, rename “Principal” to “Subject” to use the same terminology as the SAML Assertion Profile and JWT Assertion Profile specs, and apply Shawn Emery’s comments from the security directorate review.

The draft is available at:

An HTML formatted version is available at:

Page 10 of 13

Powered by WordPress & Theme by Anders Norén