Musings on Digital Identity

Month: March 2017

OpenID Connect Logout Implementer’s Drafts Approved

As announced by the OpenID Foundation, the OpenID membership has approved Implementer’s Drafts of the three OpenID Connect logout specifications. That means that developers and deployers can now count on the intellectual property protections that come with being Implementer’s Drafts.

These are the first Implementer’s Drafts of these specifications:

  • Front-Channel Logout – Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
  • Back-Channel Logout – Defines a logout mechanism that uses back-channel communication between the OP and RPs being logged out

Whereas, this is the fourth Implementer’s Draft of this specification:

  • Session Management – Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality

Each of these protocols communicate logout requests from OpenID Providers to Relying Parties, but using different mechanisms that are appropriate for different use cases. See the Introduction sections of each of the specifications for descriptions of the mechanisms used and comparisons between them. All the specifications share a common mechanism for communicating logout requests from Relying Parties to OpenID Providers.

As expected, the reviews generated some great feedback on ways to make the specs clearer. I expect the working group to incorporate that feedback in future revisions.

AMR Values specification addressing Stephen Farrell’s comments

OAuth logoSecurity area director Stephen Farrell had asked us to make it as clear as possible to people who might be registering new “amr” values that names can identify families of closely-related authentication methods. This is now said right in the IANA Registration Template, so that people who might not have read the spec can’t miss it.

FYI, all the previous IESG DISCUSSes have now been cleared, so hopefully that means this is the last version to be published before the Authentication Method Reference Values specification becomes an RFC.

Thanks again to Stephen for his always-thorough reviews of the specification.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Token Binding spec adding numerous examples and authorization code token binding

OAuth logoDraft -02 of the OAuth Token Binding specification adds example protocol messages for every distinct flow and also adds token binding for authorization codes. A lot of this is informed by implementation work that Brian Campbell has been doing, who did most of the heavy lifting for this draft. Working group members are requested to give the new text a read before IETF 98 in Chicago and to have a look at the updated open issues list. The descriptions of some of the flows were also clarified, thanks to William Denniss.

The specification is available at:

An HTML-formatted version is also available at:

Pre-Chicago OAuth Device Flow specification refinements

OAuth logoDraft -05 of the OAuth 2.0 Device Flow specification contains refinements resulting from additional reviews that have come in. This gets us ready for working group discussions at IETF 98 in Chicago. Noteworthy updates were:

  • Removed the “response_type” request parameter from the authorization request since it’s not going to the authorization endpoint.
  • Specified that parameters that are not understood must be ignored, which is standard practice for OAuth specs.
  • Added the option for the “user_code” value to be included in the request URI, facilitating QR code use cases.
  • Clarified the expiration semantics.

Thanks to William Denniss for coordinating these updates.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec incorporating WGLC feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate the working group last call feedback received. Thanks to William Denniss and Hannes Tschofenig for their reviews. Use of the “https” scheme for the “jwks_uri” URL is now required. The precedence of signed metadata values over unsigned values was clarified. Unused references were removed.

The specification is available at:

An HTML-formatted version is also available at:

Cleaner version of Using RSA Algorithms with COSE Messages specification

IETF logoI’ve published an updated version of the “Using RSA Algorithms with COSE Messages” specification with a number of editorial improvements. Changes were:

  • Reorganized the security considerations.
  • Flattened the section structure.
  • Applied wording improvements suggested by Jim Schaad.

The specification is available at:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) with better examples and a CBOR tag

IETF logoA new CBOR Web Token (CWT) draft is available with completely rewritten and much more useful examples, thanks to Samuel Erdtman. There are now examples of signed, MACed, encrypted, and nested CWTs that use all of the defined claims (and no claims not yet defined). A CBOR tag for CWTs is now also defined. People are highly encouraged to review the new examples and validate them.

The specification is available at:

An HTML-formatted version is also available at:

Powered by WordPress & Theme by Anders Norén