Mike Jones: self-issued

Musings on Digital Identity

Category: Specifications Page 4 of 23

JWK Thumbprint URI Specification

By

On November 24, 2021

In Cryptography, IETF, OAuth, OpenID, Specifications

IETF logoThe JSON Web Key (JWK) Thumbprint specification [RFC 7638] defines a method for computing a hash value over a JSON Web Key (JWK) [RFC 7517] and encoding that hash in a URL-safe manner. Kristina Yasuda and I have just created the JWK Thumbprint URI specification, which defines how to represent JWK Thumbprints as URIs. This enables JWK Thumbprints to be communicated in contexts requiring URIs, including in specific JSON Web Token (JWT) [RFC 7519] claims.

Use cases for this specification were developed in the OpenID Connect Working Group of the OpenID Foundation. Specifically, its use is planned in future versions of the Self-Issued OpenID Provider v2 specification.

The specification is available at:

Proof-of-possession (pop) AMR method added to OpenID Enhanced Authentication Profile spec

By

On October 13, 2021

In FIDO, OpenID, Phishing Resistance, Specifications, W3C

OpenID logoI’ve defined an Authentication Method Reference (AMR) value called “pop” to indicate that Proof-of-possession of a key was performed. Unlike the existing “hwk” (hardware key) and “swk” (software key) methods, it is intentionally unspecified whether the proof-of-possession key is hardware-secured or software-secured. Among other use cases, this AMR method is applicable whenever a WebAuthn or FIDO authenticator are used.

The specification is available at these locations:

Thanks to Christiaan Brand for suggesting this.

Server-contributed nonces added to OAuth DPoP

By

On October 6, 2021

In IETF, OAuth, Specifications

OAuth logoThe latest version of the “OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)” specification adds an option for servers to supply a nonce value to be included in the DPoP proof. Both authorization servers and resource servers can provide nonce values to clients.

As described in the updated Security Considerations, the nonce prevents a malicious party in control of the client (who might be a legitimate end-user) from pre-generating DPoP proofs to be used in the future and exfiltrating them to a machine without the DPoP private key. When server-provided nonces are used, actual possession of the proof-of-possession key is being demonstrated — not just possession of a DPoP proof.

The specification is available at:

OAuth 2.0 JWT-Secured Authorization Request (JAR) is now RFC 9101

By

On August 21, 2021

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

IETF logoThe OAuth 2.0 JWT-Secured Authorization Request (JAR) specification has been published as RFC 9101. Among other applications, this specification is used by the OpenID Financial-grade API (FAPI). This is another in the series of RFCs bringing OpenID Connect-defined functionality to OAuth 2.0. Previous such RFCs included “OAuth 2.0 Dynamic Client Registration Protocol” [RFC 7591] and “OAuth 2.0 Authorization Server Metadata” [RFC 8414].

The abstract of the RFC is:


The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.


This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Thanks to Nat Sakimura and John Bradley for persisting in finishing this RFC!

Second Version of FIDO2 Client to Authenticator Protocol (CTAP) Now a Standard

By

On June 23, 2021

In Cryptography, FIDO, Phishing Resistance, Privacy, Specifications

FIDO logoThe FIDO Alliance has completed the CTAP 2.1 Specification. This follows the publication of the closely-related second version of the W3C Web Authentication (WebAuthn) specification.

Today’s FIDO Alliance announcement describes the enhancements in the second version as follows:

Enhancements to FIDO standards to accelerate passwordless in the enterprise

The FIDO Alliance has announced enhancements to its FIDO2 specifications, which include several new features that will be helpful for passwordless enterprise deployments and other complex security applications. Both FIDO2 specifications were recently updated by their governing bodies — with the World Wide Web Consortium (W3C) approving WebAuthn Level 2 and FIDO doing the same for CTAP 2.1.

Key to these enhancements is enterprise attestation, which provides enterprise IT with improved management of FIDO authenticators used by employees. Enterprise attestation enables better binding of an authenticator to an account, assists with usage tracking and other management functions including credential and pin management, and biometric enrollment required in the enterprise.

Other updates include support for cross-origin iFrames and Apple attestation, as well as improvements to resident credentials. More details on these and other FIDO specification enhancements are available here.

OpenID Connect Federation updated in preparation for third Implementer’s Draft review

By

On May 25, 2021

In Federation, OpenID, Specifications

OpenID logoThe OpenID Connect Federation specification has been updated to add Security Considerations text. As discussed in the recent OpenID Connect working group calls, we are currently reviewing the specification in preparation for it becoming the third and possibly last Implementer’s Draft.

Working group members (and others!) are encouraged to provide feedback on the draft soon before we start the foundation-wide review. We will probably decide next week to progress the draft to foundation-wide review. In particular, there’s been interest recently in both Entity Statements and Automatic Registration among those working on Self-Issued OpenID Provider extensions. Reviews of those features would be particularly welcome.

The updated specification is published at:

Special thanks to Roland Hedberg for the updates!

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

By

On April 21, 2021

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

OAuth logoAs described in my last post about OAuth JAR, after it was first sent to the RFC Editor, the IESG requested an additional round of IETF feedback. I’m happy to report that, having addressed this feedback, the spec has now been sent back to the RFC Editor.

As a reminder, 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 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:

Second Version of W3C Web Authentication (WebAuthn) Now a Standard

By

On April 14, 2021

In Cryptography, FIDO, Phishing Resistance, Privacy, Specifications, W3C

W3C logoThe World Wide Web Consortium (W3C) has published this Recommendation for the Web Authentication (WebAuthn) Level 2 specification, meaning that it now a completed standard. While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format. The companion second FIDO2 Client to Authenticator Protocol (CTAP) specification is also approaching becoming a completed standard.

See the W3C announcement of this achievement. Also, see Tim Cappalli‘s summary of the changes in the second versions of WebAuthn and FIDO2.

OAuth 2.0 JWT Secured Authorization Request (JAR) updates addressing remaining review comments

By

On March 19, 2021

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

OAuth logoAfter the OAuth 2.0 JWT Secured Authorization Request (JAR) specification was sent to the RFC Editor, the IESG requested an additional round of IETF feedback. We’ve published an updated draft addressing the remaining review comments, specifically, SecDir comments from Watson Ladd. The only normative change made since the 28 was to change the MIME Type from “oauth.authz.req+jwt” to “oauth-authz-req+jwt“, per advice from the designated experts.

As a reminder, 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 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:

Second Version of W3C Web Authentication (WebAuthn) advances to Proposed Recommendation (PR)

By

On February 28, 2021

In Cryptography, Phishing Resistance, Privacy, Specifications, W3C

W3C logoThe World Wide Web Consortium (W3C) has published this Proposed Recommendation (PR) for the Web Authentication (WebAuthn) Level 2 specification, bringing the second version of WebAuthn one step closer to becoming a completed standard. While remaining compatible with the original standard, this second version adds additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format.

Near-Final Second W3C WebAuthn and FIDO2 CTAP Specifications

By

On December 31, 2020

In Cryptography, FIDO, Phishing Resistance, Privacy, Specifications, W3C

W3C logoFIDO logoThe W3C WebAuthn and FIDO2 working groups have been busy this year preparing to finish second versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications. While remaining compatible with the original standards, these second versions add additional features, among them for user verification enhancements, manageability, enterprise features, and an Apple attestation format. Near-final review drafts of both have been published:

Expect these to become approved standards in early 2021. Happy New Year!

SecEvent Delivery specs are now RFCs 8935 and 8936

By

On December 31, 2020

In IETF, JanRain, Safety, Specifications

IETF logoThe SecEvent Delivery specifications, “Push-Based Security Event Token (SET) Delivery Using HTTP” and “Poll-Based Security Event Token (SET) Delivery Using HTTP”, are now RFC 8935 and RFC 8936. Both deliver Security Event Tokens (SETs), which are defined by RFC 8417. The abstracts of the specifications are:

Push-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response.

Poll-Based Security Event Token (SET) Delivery Using HTTP:

This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient’s need for assurance.

These were designed with use cases such as Risk & Incident Sharing and Collaboration (RISC) and Continuous Access Evaluation Protocol (CAEP) in mind, both of which are happening in the OpenID Shared Signals and Events Working Group.

Concise Binary Object Representation (CBOR) Tags for Date is now RFC 8943

By

On November 20, 2020

In CBOR, IETF, Specifications

IETF logoThe Concise Binary Object Representation (CBOR) Tags for Date specification has now been published as RFC 8943. In particular, the full-date tag requested for use by the ISO Mobile Driver’s License specification in the ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification” working group has been created by this RFC. The abstract of the RFC is:


The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.


In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX “seconds since the epoch”). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.

Note that a gifted musical singer/songwriter appears in this RFC in a contextually appropriate fashion, should you need an additional incentive to read the specification. ;-)

Concise Binary Object Representation (CBOR) Tags for Date progressed to IESG Evaluation

By

On August 28, 2020

In CBOR, IETF, Specifications

IETF logoThe “Concise Binary Object Representation (CBOR) Tags for Date” specification has completed IETF last call and advanced to evaluation by the Internet Engineering Steering Group (IESG). This is the specification that defines the full-date tag requested for use by the ISO Mobile Driver’s License specification in the ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification” working group.

The specification is available at:

An HTML-formatted version is also available at:

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.

Registries for Web Authentication (WebAuthn) is now RFC 8809

By

On August 11, 2020

In FIDO, IETF, Specifications, W3C

IETF logoThe W3C Web Authentication (WebAuthn) working group created the IETF specification “Registries for Web Authentication (WebAuthn)” to establish registries needed for WebAuthn extension points. These IANA registries were populated in June 2020. Now the specification creating them has been published as RFC 8809.

Thanks again to Kathleen Moriarty and Benjamin Kaduk for their Area Director sponsorships of the specification and to Jeff Hodges and Giridhar Mandyam for their work on it.

OpenID Connect Logout specs addressing all known issues

By

On August 7, 2020

In OpenID, Specifications

OpenID logoI’ve been systematically working through all the open issues filed about the OpenID Connect Logout specs in preparation for advancing them to Final Specification status. I’m pleased to report that I’ve released drafts that address all these issues. The new drafts are:

The OpenID Connect working group waited to make these Final Specifications until we received feedback resulting from certification of logout deployments. Indeed, this feedback identified a few ambiguities and deficiencies in the specifications, which have been addressed in the latest edits. You can see the certified logout implementations at https://openid.net/certification/. We encourage you to likewise certify your implementations now.

Please see the latest History entries in the specifications for descriptions of the normative changes made. The history entries list the issue numbers addressed. The issues can be viewed in the OpenID Connect issue tracker, including links to the commits containing the changes that resolved them.

All are encouraged to review these drafts in advance of the formal OpenID Foundation review period for them, which should commence in a few weeks. If you believe that changes are needed before they become Final Specifications, please file issues describing the proposed changes. Discussion on the OpenID Connect mailing list is also encouraged.

Special thanks to Roland Hedberg for writing the initial logout certification tests. And thanks to Filip Skokan for providing resolutions to two of the thornier Session Management issues.

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

Page 4 of 23

Previous

Next

Powered by WordPress & Theme by Anders Norén