A new CBOR Web Token (CWT) draft has been published that addresses editorial comments made by Carsten Bormann and Jim Schaad. All changes were editorial in nature.
The specification is available at:
An HTML-formatted version is also available at:
Category: Specifications Page 10 of 23
The IESG approved the “Using RSA Algorithms with COSE Messages” specification for publication as an RFC today. A new version was published incorporating the IESG feedback. Thanks to Ben Campbell, Eric Rescorla, and Adam Roach for their review comments. No normative changes were made.
The specification is available at:
An HTML-formatted version is also available at:
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.
A new version of the “Using RSA Algorithms with COSE Messages” specification has been published that addresses the IETF last call feedback received. Additional security considerations were added and the IANA Considerations instructions were made more precise. Thanks to Roni Even and Steve Kent for their useful reviews!
The specification is available at:
An HTML-formatted version is also available at:
A new CBOR Web Token (CWT) draft has been published that addresses the Working Group Last Call (WGLC) feedback received. Changes were:
- Say that CWT is derived from JWT, rather than CWT is a profile of JWT.
- Used CBOR type names in descriptions, rather than major/minor type numbers.
- Clarified the NumericDate and StringOrURI descriptions.
- Changed to allow CWT claim names to use values of any legal CBOR map key type.
- Changed to use the CWT tag to identify nested CWTs instead of the CWT content type.
- Added an example using a floating-point date value.
- Acknowledged reviewers.
Thanks to Samuel Erdtman for doing the majority of the editing for this draft. As always, people are highly encouraged to validate the examples.
The specification is available at:
An HTML-formatted version is also available at:
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:
A slightly updated version of the “Using RSA Algorithms with COSE Messages” specification has been published in preparation for IETF last call. Changes were:
- Clarified the Security Considerations in ways suggested by Kathleen Moriarty.
- Acknowledged reviewers.
The specification is available at:
An HTML-formatted version is also available at:
The W3C Web Authentication working group has published the fifth working draft of the W3C Web Authentication specification. It has a new title that’s more reflective of what it enables: “Web Authentication: An API for accessing Public Key Credentials“. Among other changes, the draft is now aligned with the W3C Credential Management API. Numerous issues were resolved and many improvements in the process of creating this release.
While not a candidate recommendation, this version is informally intended by the working group to be an Implementer’s Draft, which will be used for experimenting with implementations of the API.
With the CBOR Web Token (CWT) specification nearing completion, which provides the CBOR equivalent of JWTs, I thought that it was also time to introduce the CBOR equivalent of RFC 7800, “Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)”, so that applications using CWTs will have a standard representation for proof-of-possession keys. I know that PoP keys are important to ACE applications, for instance. I therefore took RFC 7800 and produced the CBOR/CWT equivalent of it.
The specification is available at:
An HTML-formatted version is also available at:
A revised CBOR Web Token (CWT) draft has been published that corrects inconsistencies in the examples. Thanks to Jim Schaad for validating the examples and pointing out the inconsistencies and to Samuel Erdtman for fixing them. As before, people are highly encouraged to validate the updated examples.
The specification is available at:
An HTML-formatted version is also available at:
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.
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:
Draft -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:
Draft -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:
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:
I’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:
A 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:
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:
The 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:
Per discussions on the OpenID Connect working group calls, I have released candidate proposed Implementer’s Drafts for the three logout specs. The new versions are:
- http://openid.net/specs/openid-connect-session-1_0-28.html
- http://openid.net/specs/openid-connect-frontchannel-1_0-02.html
- http://openid.net/specs/openid-connect-backchannel-1_0-04.html
These drafts address the issues discussed on the calls and in the issue tracker. The changelogs can be viewed at these URLs:
- http://openid.net/specs/openid-connect-session-1_0-28.html#History
- http://openid.net/specs/openid-connect-frontchannel-1_0-02.html#History
- http://openid.net/specs/openid-connect-backchannel-1_0-04.html#History
Note that the Back-Channel Logout spec is compatible with the working group SecEvent spec https://tools.ietf.org/html/draft-ietf-secevent-token-00.
This note starts a one-week review period of these specifications by the working group. If blocking issues aren’t raised within a week, we will proceed with the formal review period preceding an OpenID Foundation Implementer’s Draft adoption vote.