Musings on Digital Identity

Category: OAuth Page 4 of 11

Security Event Token (SET) spec addressing 2nd WGLC and shepherd comments

IETF logoA new draft of the Security Event Token (SET) specification has published that addresses review comments from the second Working Group Last Call and shepherd comments from Yaron Sheffer. Changes were:

  • Changed “when the event was issued” to “when the SET was issued” in the “iat” description, as suggested by Annabelle Backman.
  • Applied editorial improvements that improve the consistency of the specification that were suggested by Annabelle Backman, Marius Scurtescu, and Yaron Sheffer.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec addressing IESG feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to address feedback received from IESG members. Changes were:

  • Revised the transformation between the issuer identifier and the authorization server metadata location to conform to BCP 190, as suggested by Adam Roach.
  • Defined the characters allowed in registered metadata names and values, as suggested by Alexey Melnikov.
  • Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate, as suggested by Ben Campbell.
  • Acknowledged additional reviewers.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Token Exchange spec addressing Area Director feedback

OAuth logoA new draft of the OAuth 2.0 Token Exchange specification has been published that addresses feedback from Security Area Director Eric Rescorla. The acknowledgements were also updated. Thanks to Brian Campbell for doing the editing for this version.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Token Exchange spec adding URIs for SAML assertions

OAuth logoA new draft of the OAuth 2.0 Token Exchange specification has been published that adds token type URIs for SAML 1.1 and SAML 2.0 assertions. They were added in response to actual developer use cases. These parallel the existing token type URI for JWT tokens.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata spec incorporating IETF last call feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate feedback received during IETF last call. Thanks to Shwetha Bhandari, Brian Carpenter, Donald Eastlake, Dick Hardt, and Mark Nottingham for their reviews. See the Document History appendix for clarifications applied. No normative changes were made.

The specification is available at:

An HTML-formatted version is also available at:

OAuth and OpenID Connect Token Binding specs updated

OAuth logoThe OAuth 2.0 Token Binding specification has been updated to enable Token Binding of JWT Authorization Grants and JWT Client Authentication. The discussion of phasing in Token Binding was improved and generalized. See the Document History section for other improvements applied.

The specification is available at:

An HTML-formatted version is also available at:

An update to the closely-related OpenID Connect Token Bound Authentication 1.0 specification was also simultaneously published. Its discussion of phasing in Token Binding was correspondingly updated.

The OpenID Connect Token Binding specification is available in HTML and text versions at:

Thanks to Brian Campbell for doing the bulk of the editing for both sets of revisions.

OAuth Authorization Server Metadata spec incorporating Area Director feedback

OAuth logoThe OAuth Authorization Server Metadata specification has been updated to incorporate feedback from Security Area Director Eric Rescorla. Thanks to EKR for his useful review. A number of defaults and restrictions are now better specified.

The specification is available at:

An HTML-formatted version is also available at:

Initial working group draft of JSON Web Token Best Current Practices

OAuth logoI’m happy to announce that the OAuth working group adopted the JSON Web Token Best Current Practices (JWT BCP) draft that Yaron Sheffer, Dick Hardt, and I had worked on, following discussions at IETF 99 in Prague and on the working group mailing list.

The specification is available at:

An HTML-formatted version is also available at:

JSON Web Token Best Current Practices draft describing Explicit Typing

OAuth logoThe JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs. This is accomplished by including an explicit type for the JWT in the “typ” header parameter. For instance, the Security Event Token (SET) specification now uses the “application/secevent+jwt” content type to explicitly type SETs.

The specification is available at:

An HTML-formatted version is also available at:

Authentication Method Reference Values is now RFC 8176

IETF logoThe Authentication Method Reference Values specification is now RFC 8176. The abstract describes the specification as:

The amr (Authentication Methods References) claim is defined and registered in the IANA “JSON Web Token Claims” registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

The specification defines and registers some Authentication Method Reference values such as the following, which are already in use by some Google and Microsoft products and OpenID specifications:

  • face” — Facial recognition
  • fpt” — Fingerprint
  • hwk” — Proof-of-possession of a hardware-secured key
  • otp” — One-time password
  • pin” — Personal Identification Number
  • pwd” — Password
  • swk” — Proof-of-possession of a software-secured key
  • sms” — Confirmation using SMS
  • user” — User presence test
  • wia” — Windows Integrated Authentication

See https://www.iana.org/assignments/authentication-method-reference-values/ for the full list of registered values.

Thanks to Caleb Baker, Phil Hunt, Tony Nadalin, and William Denniss, all of whom substantially contributed to the specification. Thanks also to the OAuth working group members, chairs, area directors, and other IETF members who helped refine the specification.

Initial JSON Web Token Best Current Practices Draft

OAuth logoJSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) functions underlying them are now being widely used in diverse sets of applications. During IETF 98 in Chicago, we discussed reports of people implementing and using JOSE and JWTs insecurely, the causes of these problems, and ways to address them. Part of this discussion was an invited JOSE/JWT Security Update presentation that I gave to two working groups, which included links to problem reports and described mitigations. Citing the widespread use of JWTs in new IETF applications, Security Area Director Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written for JSON Web Tokens (JWTs).

I’m happy to report that Yaron Sheffer, Dick Hardt, and myself have produced an initial draft of a JWT BCP. Its abstract is:

JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs.

In Section 2, we describe threats and vulnerabilities. In Section 3, we describe best practices addressing those threats and vulnerabilities. We believe that the best practices in Sections 3.1 through 3.8 are ready to apply today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) describes several possible best practices on that topic to serve as a starting point for a discussion on which of them we want to recommend under what circumstances.

We invite input from the OAuth Working Group and other interested parties on what best practices for JSON Web Tokens and the JOSE functions underlying them should be. We look forward to hearing your thoughts and working on this specification together.

The specification is available at:

An HTML-formatted version is also available at:

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:

AMR Values specification addressing IESG comments

OAuth logoThe Authentication Method Reference Values specification has been updated to address feedback from the IESG. Identifiers are now restricted to using only printable JSON-friendly ASCII characters. All the “amr” value definitions now include specification references.

Thanks to Stephen Farrell, Alexey Melnikov, Ben Campbell, and Jari Arkko for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Device Flow specification nearly done

OAuth logoThe OAuth 2.0 Device Flow specification has been updated to flesh out some of the parts that were formerly missing or incomplete. Updates made were:

  • Updated the title to “OAuth 2.0 Device Flow for Browserless and Input Constrained Devices” to reflect the specificity of devices that use this flow.
  • User Instruction section expanded.
  • Security Considerations section added.
  • Usability Considerations section added.
  • Added OAuth 2.0 Authorization Server Metadata definition for the device authorization endpoint.

It’s my sense that this specification is now nearly done. I highly encourage those of you with device flow implementations to review this version with an eye towards ensuring that all the functionality needed for your use cases is present. For instance, I’d suggest comparing the error code definitions to your usage.

Thanks to William Denniss for producing these updates.

The specification is available at:

An HTML-formatted version is also available at:

“amr” Values specification addressing IETF last call comments

OAuth logoDraft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:

  • Specified characters allowed in “amr” values, reusing the IANA Considerations language on this topic from RFC 7638.
  • Added several individuals to the acknowledgements.

Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their reviews.

The specification is available at:

An HTML-formatted version is also available at:

OAuth Authorization Server Metadata decoupled from OAuth Protected Resource Metadata

OAuth logoThe IETF OAuth working group decided at IETF 97 to proceed with standardizing the OAuth Authorization Server Metadata specification, which is already in widespread use, and to stop work on the OAuth Protected Resource Metadata specification, which is more speculative. Accordingly, a new version of the AS Metadata spec has been published that removes its dependencies upon the Resource Metadata spec. In particular, the “protected_resources” AS Metadata element has been removed. Its definition has been moved to the Resource Metadata spec for archival purposes. Note that the Resource Metadata specification authors intend to let it expire unless the working group decides to resume work on it at some point in the future.

The specifications are available at:

HTML-formatted versions are also available at:

“amr” Values specification addressing area director comments

OAuth logoDraft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were:

  • Added “amr” claim examples with both single and multiple values.
  • Clarified that the actual credentials referenced are not part of this specification to avoid additional privacy concerns for biometric data.
  • Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to applications using this specification.

The specification is available at:

An HTML-formatted version is also available at:

Page 4 of 11

Powered by WordPress & Theme by Anders Norén