Mike Jones: self-issued

Musings on Digital Identity

Category: JSON Page 2 of 12

OAuth 2.0 JWT Secured Authorization Request (JAR) sent to the RFC Editor

By

On August 20, 2020

In Claims, IETF, JSON, OAuth, OpenID, Specifications

OAuth logoCongratulations to Nat Sakimura and John Bradley for progressing the OAuth 2.0 JWT Secured Authorization Request (JAR) specification from the working group through the IESG to the RFC Editor. This specification takes the JWT Request Object from Section 6 of OpenID Connect Core (Passing Request Parameters as JWTs) and makes this functionality available for pure OAuth 2.0 applications — and intentionally does so without introducing breaking changes.

This is one of a series of specifications bringing functionality originally developed for OpenID Connect to the OAuth 2.0 ecosystem. Other such specifications included OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414].

The specification is available at:

An HTML-formatted version is also available at:

Again, congratulations to Nat and John and the OAuth Working Group for this achievement!

COSE and JOSE Registrations for Web Authentication (WebAuthn) Algorithms is now RFC 8812

By

On August 14, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThe W3C Web Authentication (WebAuthn) working group and the IETF COSE working group created “CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms” to make some algorithms and elliptic curves used by WebAuthn and FIDO2 officially part of COSE and JOSE. The RSA algorithms are used by TPMs. The “secp256k1” curve registered (a.k.a., the Bitcoin curve) is also used in some decentralized identity applications. The completed specification has now been published as RFC 8812.

As described when the registrations recently occurred, the algorithms registered are:

  • RS256 — RSASSA-PKCS1-v1_5 using SHA-256 — new for COSE
  • RS384 — RSASSA-PKCS1-v1_5 using SHA-384 — new for COSE
  • RS512 — RSASSA-PKCS1-v1_5 using SHA-512 — new for COSE
  • RS1 — RSASSA-PKCS1-v1_5 using SHA-1 — new for COSE
  • ES256K — ECDSA using secp256k1 curve and SHA-256 — new for COSE and JOSE

The elliptic curves registered are:

  • secp256k1 — SECG secp256k1 curve — new for COSE and JOSE

See them in the IANA COSE Registry and the IANA JOSE Registry.

SecEvent Delivery specs sent to the RFC Editor

By

On June 29, 2020

In IETF, JSON, Safety, Specifications

IETF logoI’m pleased to report that the SecEvent delivery specifications are now stable, having been approved by the IESG, and will shortly become RFCs. Specifically, they have now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specifications with confidence that that breaking changes will not occur as they are finalized.

The specifications are available at:

HTML-formatted versions are also available at:

Registrations for all WebAuthn algorithm identifiers completed

By

On June 19, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoWe wrote the specification COSE and JOSE Registrations for WebAuthn Algorithms to create and register COSE and JOSE algorithm and elliptic curve identifiers for algorithms used by WebAuthn and CTAP2 that didn’t yet exist. I’m happy to report that all these registrations are now complete and the specification has progressed to the RFC Editor. Thanks to the COSE working group for supporting this work.

Search for WebAuthn in the IANA COSE Registry and the IANA JOSE Registry to see the registrations. These are now stable and can be used by applications, both in the WebAuthn/FIDO2 space and for other application areas, including decentralized identity (where the secp256k1 “bitcoin curve” is in widespread use).

The algorithms registered are:

  • RS256 — RSASSA-PKCS1-v1_5 using SHA-256 — new for COSE
  • RS384 — RSASSA-PKCS1-v1_5 using SHA-384 — new for COSE
  • RS512 — RSASSA-PKCS1-v1_5 using SHA-512 — new for COSE
  • RS1 — RSASSA-PKCS1-v1_5 using SHA-1 — new for COSE
  • ES256K — ECDSA using secp256k1 curve and SHA-256 — new for COSE and JOSE

The elliptic curves registered are:

  • secp256k1 — SECG secp256k1 curve — new for COSE and JOSE

secp256k1 curve and algorithm registered for JOSE use

By

On May 31, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoIANA has registered the “secp256k1” elliptic curve in the JSON Web Key Elliptic Curve registry and the corresponding “ES256K” signing algorithm in the JSON Web Signature and Encryption Algorithms registry. This curve is widely used among blockchain and decentralized identity implementations.

The registrations were specified by the COSE and JOSE Registrations for WebAuthn Algorithms specification, which was created by the W3C Web Authentication working group and the IETF COSE working group because WebAuthn also allows the use of secp256k1. This specification is now in IETF Last Call. The corresponding COSE registrations will occur after the specification becomes an RFC.

Nearing completion on two WebAuthn-related specs at the IETF

By

On May 14, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThis week we published updates to two IETF specifications that support the WebAuthn/FIDO2 ecosystem, as well as other uses, such as decentralized identity.

One is COSE and JOSE Registrations for WebAuthn Algorithms. It registers algorithm and elliptic curve identifiers for algorithms used by WebAuthn and FIDO2. The “secp256k1” curve being registered is also used for signing in some decentralized identity applications. The specification has completed the Area Director review and has been submitted to the IESG for publication.

The other is Registries for Web Authentication (WebAuthn). This creates IANA registries enabling multiple kinds of extensions to W3C Web Authentication (WebAuthn) implementations to be registered. This specification has completed IETF last call and is scheduled for review by the IESG.

Thanks to the COSE working group for their adoption of the algorithms specification, and to Ivaylo Petrov and Murray Kucherawy for their reviews of it. Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area Director sponsorships of the registries specification and to Jeff Hodges for being primary author of it.

The specifications are available at:

JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

By

On February 19, 2020

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoThe JSON Web Token Best Current Practices specification is now RFC 8725 and BCP 225. The abstract of the specification is:

JSON Web Tokens, also known as JWTs, 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. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519] was approved in May 2015, almost five years ago, and has been in production use since at least 2013. This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise. Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others. For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party’s authorization to use a particular telephone number for an incoming call, providing verified Caller ID to help combat fraudulent and unwanted telephone calls. The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

COSE and JOSE Registrations for WebAuthn Algorithms spec adding explanatory comments on design decisions

By

On January 27, 2020

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to add explanatory comments on design decisions made that were discussed on the mailing list that Jim Schaad requested be added to the draft.

The specification is available at:

An HTML-formatted version is also available at:

Poll-Based Security Event Token (SET) Delivery spec addressing WGLC and Shepherd comments

By

On November 18, 2019

In IETF, JSON, Specifications

IETF logoThe Poll-Based Security Event Token (SET) Delivery specification has been updated to address Working Group Last Call (WGLC) and Document Shepherd comments received. Thanks to Annabelle Backman for the useful WGLC comments and to Yaron Sheffer for the useful Shepherd comments. This update is intended to enable our area director Benjamin Kaduk to review both the Push and Poll delivery method specifications at the same time.

The specification is available at:

An HTML-formatted version is also available at:

COSE and JOSE Registrations for WebAuthn Algorithms spec addressing WGLC comments

By

On October 24, 2019

In CBOR, Cryptography, FIDO, IETF, JSON, Specifications, W3C

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address working group last call (WGLC) feedback received. Thanks to J.C. Jones, Kevin Jacobs, Jim Schaad, Neil Madden, and Benjamin Kaduk for their useful reviews.

The specification is available at:

An HTML-formatted version is also available at:

JSON Web Token Best Current Practices sent to the RFC Editor

By

On October 22, 2019

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoI’m pleased to report that the JSON Web Token (JWT) Best Current Practices (BCP) specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

JSON Web Tokens, also known as JWTs, 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.

Thanks to the OAuth working group for completing this important specification.

The specification is available at:

An HTML-formatted version is also available at:

OAuth 2.0 Token Exchange specification sent to the RFC Editor

By

On July 24, 2019

In Claims, IETF, JSON, OAuth, Specifications

OAuth logoI’m very pleased to report that the OAuth 2.0 Token Exchange specification is now technically stable and will shortly be an RFC — an Internet standard. Specifically, it has now progressed to the RFC Editor queue, meaning that the only remaining step before finalization is editorial due diligence. Thus, implementations can now utilize the draft specification with confidence that that breaking changes will not occur as it is finalized.

The abstract of the specification is:

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

Thanks to the OAuth working group for completing this important specification. And thanks to Brian Campbell for taking point in making the recent updates to get us here.

The specification is available at:

An HTML-formatted version is also available at:

Refinements to COSE and JOSE Registrations for WebAuthn Algorithms

By

On July 8, 2019

In CBOR, Cryptography, IETF, JSON, Specifications, W3C

IETF logoThe “COSE and JOSE Registrations for WebAuthn Algorithms” specification has been updated to address feedback received since working group adoption. The one breaking change is changing the secp256k1 curve identifier for JOSE from “P-256K” to “secp256k1“, for reasons described by John Mattsson. The draft now also specifies that the SHA-256 hash function is to be used with “ES256K” signatures – a clarification due to Matt Palmer.

The specification is available at:

An HTML-formatted version is also available at:

Working group adoption of “COSE and JOSE Registrations for WebAuthn Algorithms”

By

On March 27, 2019

In CBOR, Cryptography, IETF, JSON, Specifications, W3C

IETF logoI’m pleased to report that the IETF COSE Working Group has adopted the specification “COSE and JOSE Registrations for WebAuthn Algorithms”. An abstract of what it does is:

This specification defines how to use several algorithms with COSE [RFC8152] that are used by implementations of the W3C Web Authentication (WebAuthn) [WebAuthn] and FIDO2 Client to Authenticator Protocol (CTAP) [CTAP] specifications. These algorithms are to be registered in the IANA “COSE Algorithms” registry [IANA.COSE.Algorithms] and also in the IANA “JSON Web Signature and Encryption Algorithms” registry [IANA.JOSE.Algorithms], when not already registered there.

The algorithms registered are RSASSA-PKCS1-v1_5 with four different hash functions and signing with the secp256k1 curve. Note that there was consensus in the working group meeting not to work on registrations for the Elliptic Curve Direct Anonymous Attestation (ECDAA) algorithms “ED256” and “ED512“, both because of issues that have been raised with them and because they are not in widespread use.

The -01 version will address the review comments received on the mailing list from Jim Schaad and John Mattsson.

The specification is available at:

An HTML-formatted version is also available at:

Additional COSE algorithms used by W3C Web Authentication (WebAuthn)

By

On March 11, 2019

In CBOR, Cryptography, IETF, JSON, Specifications, W3C

IETF logoThe new COSE working group charter includes this deliverable:

4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point (Informational).

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 specification is available at:

An HTML-formatted version is also available at:

JWT BCP updates addressing Area Director review comments

By

On November 8, 2018

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

OAuth logoThe 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 specification is available at:

An HTML-formatted version is also available at:

Security Event Token (SET) is now RFC 8417

By

On July 10, 2018

In Claims, IETF, JSON, OpenID, Specifications

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

SETs are already in use to represent OpenID Connect Back-Channel Logout tokens and to represent Risk and Incident Sharing and Coordination (RISC) events. Thanks to my co-editors, members of the IETF ID Events mailing list, and members of the IETF Security Events working group for making this standard a reality!

OAuth 2.0 Authorization Server Metadata is now RFC 8414

By

On June 28, 2018

In Claims, IETF, JSON, OAuth, OpenID, Specifications

OAuth logoThe 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.

Having a standard OAuth metadata format makes it easier for OAuth clients to configure connections to OAuth authorization servers. See https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata for the initial set of registered metadata values.

Thanks to all of you who helped make this standard a reality!

Security Event Token (SET) updates addressing IESG feedback

By

On May 9, 2018

In Claims, IETF, JSON, Specifications

IETF logoWe’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:

An HTML-formatted version is also available at:

JWT BCP updates addressing WGLC feedback

By

On May 9, 2018

In Claims, Cryptography, IETF, JSON, OAuth, Specifications

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

An HTML-formatted version is also available at:

Page 2 of 12

Previous

Next

Powered by WordPress & Theme by Anders Norén