Mike Jones: self-issued

Musings on Digital Identity

Month: June 2017

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) spec addressing review comments

By

On June 30, 2017

In CBOR, Claims, Cryptography, Specifications

IETF logoThe Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification has been updated to address comments received since its initial publication. Changes were:

  • Tracked CBOR Web Token (CWT) Claims Registry updates.
  • Addressed review comments by Michael Richardson and Jim Schaad.
  • Added co-authors Ludwig Seitz, Göran Selander, Erik Wahlström, Samuel Erdtman, and Hannes Tschofenig.

Thanks for the feedback received to date!

The specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) specification preventing token confusion

By

On June 30, 2017

In Claims, JSON, Specifications

IETF logoA 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:

An HTML-formatted version is also available at:

CBOR Web Token (CWT) specification addressing editorial comments

By

On June 29, 2017

In CBOR, Claims, Specifications

IETF logoA 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:

“Using RSA Algorithms with COSE Messages” specification approved for publication

By

On June 22, 2017

In CBOR, Cryptography, Specifications

IETF logoThe 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:

Authentication Method Reference Values is now RFC 8176

By

On June 16, 2017

In Claims, JSON, OAuth, OpenID, Specifications

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.

“Using RSA Algorithms with COSE Messages” specification addressing IETF last call feedback

By

On June 15, 2017

In CBOR, Cryptography, Specifications

IETF logoA 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:

CBOR Web Token (CWT) specification addressing WGLC feedback

By

On June 5, 2017

In CBOR, Claims, Specifications

IETF logoA 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:

Initial JSON Web Token Best Current Practices Draft

By

On June 4, 2017

In Claims, Cryptography, JSON, OAuth, Specifications

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:

Powered by WordPress & Theme by Anders Norén