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:
An HTML-formatted version is also available at:
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:
The specification is available at:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
iat” description, as suggested by Annabelle Backman.The specification is available at:
An HTML-formatted version is also available at:
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:
The specification is available at:
An HTML-formatted version is also available at:
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:
iat” and “toe” claims in ways suggested by Annabelle Backman.Thanks to Annabelle Backman, Marius Scurtescu, Phil Hunt, and Dick Hardt for the discussions that led to these simplifications.
The specification is available at:
An HTML-formatted version is also available at:
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:
No changes to the semantics of the specification were made.
The specification is available at:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
application/secevent+jwt media type and defined how to use it for explicit typing of SETs.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:
An HTML-formatted version is also available at:
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 recognitionfpt” – Fingerprinthwk” – Proof-of-possession of a hardware-secured keyotp” – One-time passwordpin” – Personal Identification Numberpwd” – Passwordswk” – Proof-of-possession of a software-secured keysms” – Confirmation using SMSuser” – User presence testwia” – Windows Integrated AuthenticationSee 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:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
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:
An HTML-formatted version is also available at:
No Comments » Posted under Claims & JSON & OAuth & Specifications
The 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:
No Comments » Posted under Claims & JSON & OAuth & OpenID & Specifications
Draft -05 of the Authentication Method Reference Values specification addresses the IETF last call comments received. Changes were:
amr” values, reusing the IANA Considerations language on this topic from RFC 7638.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:
No Comments » Posted under Claims & JSON & OAuth & OpenID & Specifications
The 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:
No Comments » Posted under Claims & JSON & OAuth & Specifications
As those of you who have been following the id-event@ietf.org mailing list or attended the inaugural meeting of the new IETF Security Events working group know, Phil Hunt and co-authors (including myself) have been working on a Security Event Token (SET) specification. A SET is a JSON Web Token (JWT) with an “events” claim that contains one or more event identifiers (which are URIs) that say what event the SET describes.
This work isn’t being done in isolation. Among others, the OpenID Risk and Incident Sharing and Coordination (RISC) working group, the OpenID Back-Channel Logout specification, and the SCIM Provisioning Events work intend to use the Security Event Token format.
To make this concrete, the claims in an example OpenID Connect Back-Channel Logout token (which is a SET) are:
{
"iss": "https://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"iat": 1471566154,
"jti": "bWJq",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
"events": {
"http://schemas.openid.net/event/backchannel-logout": {}
}
}
You’ll see that this a normal JWT, with the issuer, subject, and session ID identifying the target of the logout, and the “events” value identifying the JWT as a logout SET.
Today, we published an updated SET spec based on discussions at IETF 97, which simplifies the SET parsing. Thanks to Phil Hunt or Oracle, William Denniss of Google, Morteza Ansari of Cisco, and the numerous other contributors who’ve gotten us to this point. We now believe that this specification is ready for adoption by the Security Events working group.
The specification is available at:
An HTML-formatted version is also available at:
The OpenID Connect Back-Channel Logout specification should be updated soon (after the US Thanksgiving holiday) to utilize the simplified SET syntax. Happy Thanksgiving, everyone!
No Comments » Posted under Claims & JSON & OpenID & Specifications
