Mike Jones: self-issued

We’ve updated the Security Event Token (SET) specification to address feedback received from Internet Engineering Steering Group (IESG) members. We’ve actually published three versions in quick succession in preparation for tomorrow’s evaluation by the IESG.

Draft -11 incorporated feedback from Security Area Director Eric Rescorla and IANA Designated Expert Ned Freed. Changes were:

• Clarified “iss” claim language about the SET issuer versus the security subject issuer.
• Changed a “SHOULD” to a “MUST” in the “sub” claim description to be consistent with the Requirements for SET Profiles section.
• Described the use of the “events” claim to prevent attackers from passing off other kinds of JWTs as SETs.
• Stated that SETs are to be signed by an issuer that is trusted to do so for the use case.
• Added quotes in the phrase ‘”token revoked” SET to be issued’ in the Timing Issues section.
• Added section number references to the media type and media type suffix registrations.
• Changed the encodings of the media type and media type suffix registrations to binary (since no line breaks are allowed).
• Replaced a “TBD” in the media type registration with descriptive text.
• Acknowledged Eric Rescorla and Ned Freed.

Draft -12 incorporated feedback from Adam Roach, Alexey Melnikov, and Alissa Cooper. Changes were:

• Removed unused references to RFC 7009 and RFC 7517.
• Corrected name of RFC 8055 in Section 4.3 to “Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm”.
• Added normative references for base64url and UTF-8.
• Section 5.1 – Changed SHOULD to MUST in “personally identifiable information MUST be encrypted using JWE [RFC7516] or …”.
• Section 5.2 – Changed “MUST consider” to “must consider”.
• Acknowledged Adam Roach, Alexey Melnikov, and Alissa Cooper.

Draft -13 incorporated feedback from Martin Vigoureaux. Changes were:

• Changed a non-normative “MAY” to “may” in Section 1.1.
• Acknowledged Martin Vigoureux and Mirja Kühlewind.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-13

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-13.html

No Comments » Posted under Claims & IETF & JSON & Specifications

The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the Working Group Last Call (WGLC) feedback received. Thanks to Neil Madden for his numerous comments and to Carsten Bormann and Brian Campbell for their reviews.

Assuming the chairs concur, the next step should be to request publication.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-03.html

No Comments » Posted under Claims & Cryptography & IETF & JSON & OAuth & Specifications

An updated Security Event Token (SET) specification has published to address recent review comments received. Changes were:

• Incorporated wording improvements resulting from Russ Housley’s additional SecDir comments.
• Registered +jwt structured syntax suffix.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-10

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-10.html

No Comments » Posted under Claims & IETF & JSON & Specifications

The syntax of two JWT claims registered by the OAuth Token Exchange specification has been changed as a result of developer feedback. Developers pointed out that the OAuth Token Introspection specification [RFC 7662] uses a “scope” string to represent scope values, whereas Token Exchange was defining an array-valued “scp” claim to represent scope values. The former also uses a “client_id” element to represent OAuth Client ID values, whereas the latter was using a “cid” claim for the same purpose.

After consulting with the working group, the OAuth Token Exchange claim names have been changed to “scope” and “client_id”. Thanks to Torsten Lodderstedt for pointing out the inconsistencies and to Brian Campbell for seeking consensus and making the updates.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-13

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-token-exchange-13.html

No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications

The Security Event Token (SET) specification has been updated to address Area Director review comments from Benjamin Kaduk. Thanks for the thorough and useful review, as always, Ben.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-09

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-09.html

No Comments » Posted under Claims & IETF & JSON & Specifications

A new draft of the Security Event Token (SET) specification has published that addresses comments from Russ Housley, who reviewed the spec for the IETF Security Directorate (SecDir). Changes were:

• Incorporated wording improvements resulting from Russ Housley’s SecDir comments.
• Acknowledged individuals who made significant contributions.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-08

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-08.html

No Comments » Posted under Claims & IETF & JSON & Specifications

The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to add guidance on how to explicitly type Nested JWTs. Thanks to Brian Campbell for suggesting the addition.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-01

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-01.html

No Comments » Posted under Claims & Cryptography & IETF & JSON & OAuth & Specifications

The OAuth Authorization Server Metadata specification has been updated to address additional IESG feedback. The only change was to clarify the meaning of “case-insensitive”, as suggested by Alexey Melnikov.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-oauth-discovery-10

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-discovery-10.html

No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications

A 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:

• https://tools.ietf.org/html/draft-ietf-secevent-token-06

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-06.html

No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications

The 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:

• https://tools.ietf.org/html/draft-ietf-oauth-discovery-09

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-discovery-09.html

No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications

The Security Event Token (SET) specification has been updated to simplify the definitions and usage of the “iat” (issued at) and “toe” (time of event) claims. The full set of changes made was:

• Simplified the definitions of the “iat” and “toe” claims in ways suggested by Annabelle Backman.
• Added privacy considerations text suggested by Annabelle Backman.
• Updated the RISC event example, courtesy of Marius Scurtescu.
• Reordered the claim definitions to place the required claims first.
• Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

Thanks to Annabelle Backman, Marius Scurtescu, Phil Hunt, and Dick Hardt for the discussions that led to these simplifications.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-05

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-05.html

No Comments » Posted under Claims & IETF & JSON & OpenID & Specifications

A new version of the Security Event Token (SET) specification has been published that incorporates clarifications suggested by working group members in discussions since IETF 100. Changes were:

• Clarified that all “events” values must represent aspects of the same state change that occurred to the subject — not an aggregation of unrelated events about the subject.
• Removed ambiguities about the roles of multiple “events” values and the responsibilities of profiling specifications for defining how and when they are used.
• Corrected places where the term JWT was used when what was actually being discussed was the JWT Claims Set.
• Addressed terminology inconsistencies. In particular, standardized on using the term “issuer” to align with JWT terminology and the “iss” claim. Previously the term “transmitter” was sometimes used and “issuer” was sometimes used. Likewise, standardized on using the term “recipient” instead of “receiver” for the same reasons.
• Added a RISC event example, courtesy of Marius Scurtescu.
• Applied wording clarifications suggested by Annabelle Backman and Yaron Sheffer.
• Applied numerous grammar, syntax, and formatting corrections.

No changes to the semantics of the specification were made.

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-04

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-04.html

No Comments » Posted under Claims & IETF & JSON & OpenID & Specifications

The 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:

• https://tools.ietf.org/html/draft-ietf-oauth-discovery-08

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-discovery-08.html

No Comments » Posted under Claims & IETF & JSON & OAuth & Specifications

I’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:

• https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-00

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-jwt-bcp-00.html

No Comments » Posted under Claims & Cryptography & IETF & JSON & OAuth & Specifications

The 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:

• https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html

No Comments » Posted under Claims & Cryptography & JSON & OAuth & Specifications

A new version of the Security Event Token (SET) specification has been published containing measures that prevent any possibility of confusion between ID Tokens and SETs. Preventing confusion between SETs, access tokens, and other kinds of JWTs is also covered. Changes were:

• Added the Requirements for SET Profiles section.
• Expanded the Security Considerations section to describe how to prevent confusion of SETs with ID Tokens, access tokens, and other kinds of JWTs.
• Registered the application/secevent+jwt media type and defined how to use it for explicit typing of SETs.
• Clarified the misleading statement that used to say that a SET conveys a single security event.
• Added a note explicitly acknowledging that some SET profiles may choose to convey event subject information in the event payload.
• Corrected an encoded claims set example.
• Applied grammar corrections.

This draft is intended to provide solutions to the issues that had been discussed in IETF 98 in Chicago and subsequently on the working group mailing list. Thanks for all the great discussions that informed this draft!

The specification is available at:

• https://tools.ietf.org/html/draft-ietf-secevent-token-02

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-secevent-token-02.html

No Comments » Posted under Claims & JSON & Specifications

The 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.

No Comments » Posted under Claims & JSON & OAuth & OpenID & Specifications

JSON 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:

• https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html

No Comments » Posted under Claims & Cryptography & JSON & OAuth & Specifications

Security 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:

• https://tools.ietf.org/html/draft-ietf-oauth-amr-values-08

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-amr-values-08.html

No Comments » Posted under Claims & JSON & OAuth & OpenID & Specifications

The 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:

• https://tools.ietf.org/html/draft-ietf-oauth-discovery-06

An HTML-formatted version is also available at:

• http://self-issued.info/docs/draft-ietf-oauth-discovery-06.html

No Comments » Posted under Claims & JSON & OAuth & Specifications