I have written draft-jones-cose-additional-algorithms, which combines these starting points into a single draft, which registers these algorithms in the IANA COSE registries. When not already registered, this draft also registers these algorithms for use with JOSE in the IANA JOSE registries. I believe that this draft is ready for working group adoption to satisfy this deliverable.
The JSON Web Token (JWT) Best Current Practices (BCP) specification has been updated to address the review comments from Security Area Director (AD) Eric Rescorla. Thanks to Eric for the review and to Yaron Sheffer for working on the responses with me.
Note that IETF publication has already been requested. The next step is for the shepherd review to be submitted and responded to.
The Security Event Token (SET) specification is now RFC 8417. The abstract describes the specification as:
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.
The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414. The abstract describes the specification as:
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
The specification defines a JSON metadata representation for OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0. This specification is a true instance of standardizing existing practice. OAuth 2.0 deployments have been using the OpenID Connect metadata format to describe their endpoints and capabilities for years. This RFC makes this existing practice a standard.
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.
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 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 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.
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.
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.
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:
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:
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.