Building the Internet's missing identity layer
I gave the following invited “101” session presentation at the 31st Internet Identity Workshop (IIW) on Tuesday, October 20, 2020:
I appreciated learning about how the participants are using or considering using OpenID Connect. The session was recorded and will be available in the IIW proceedings.
The “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:
Congratulations 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!
The 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 COSERS384 — RSASSA-PKCS1-v1_5 using SHA-384 — new for COSERS512 — RSASSA-PKCS1-v1_5 using SHA-512 — new for COSERS1 — RSASSA-PKCS1-v1_5 using SHA-1 — new for COSEES256K — ECDSA using secp256k1 curve and SHA-256 — new for COSE and JOSEThe elliptic curves registered are:
secp256k1 — SECG secp256k1 curve — new for COSE and JOSESee them in the IANA COSE Registry and the IANA JOSE Registry.
The 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.
I’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.
My Identiverse 2020 talk Enabling Scalable Multi-lateral Federations with OpenID Connect was just broadcast and is available for viewing. The talk abstract is:
Numerous large-scale multi-lateral identity federations are in production use today, primarily in the Research and Education sector. These include national federations, such as SWAMID in Sweden and InCommon in the US, some with thousands of sites, and inter-federations among dozens of federations, such as eduGAIN. Yet these existing federations are based on SAML 2 and require the federation operator to poll the participants for their metadata, concatenating it into a huge file that is distributed to all federation participants nightly — a brittle process with significant scalability problems.
Responding to demand from the Research and Education community to migrate from SAML 2 to the simpler OpenID Connect protocol, the OpenID Connect working group has created the OpenID Connect Federation specification to enable this. The new approach incorporates lessons learned from existing SAML 2 federations — especially using a new, scalable approach to federation metadata, in which organizations host their own signed metadata and federation operators in turn sign statements about the organizations that are participants in the federation. As Shibboleth author Scott Cantor publicly said at a federation conference, “Given all my experience, if I were to redo the metadata handling today, I would do it along the lines in the OpenID Connect Federation specification”.
This presentation will describe progress implementing and deploying OpenID Connect Federation, upcoming interop events and results, and next steps to complete the specification and foster production deployments. The resulting feedback from Identiverse participants on the approach will be highly valuable.
As a late-breaking addition, data from the June 2020 Federation interop event organized by Roland Hedberg was included in the presentation.
You can also view the presentation slides as PowerPoint or PDF.
I’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:
We 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 COSERS384 — RSASSA-PKCS1-v1_5 using SHA-384 — new for COSERS512 — RSASSA-PKCS1-v1_5 using SHA-512 — new for COSERS1 — RSASSA-PKCS1-v1_5 using SHA-1 — new for COSEES256K — ECDSA using secp256k1 curve and SHA-256 — new for COSE and JOSEThe elliptic curves registered are:
secp256k1 — SECG secp256k1 curve — new for COSE and JOSEThe SecEvent delivery specifications have been revised to unambiguously require the use of TLS, while preserving descriptions of precautions needed for non-TLS use in non-normative appendices. Thanks to the Security Events and Shared Signals and Events working group members who weighed in on this decision. I believe these drafts are now ready to be scheduled for an IESG telechat.
The updated specifications are available at:
HTML-formatted versions are also available at:
The CBOR tags for the date representations defined by the “Concise Binary Object Representation (CBOR) Tags for Date” specification have been registered in the IANA Concise Binary Object Representation (CBOR) Tags registry. This means that they’re now ready for use by applications. 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 is now good to go.
FYI, I also updated the spec to incorporate a few editorial suggestions by Carsten Bormann. The new draft changed “positive or negative” to “unsigned or negative” and added an implementation note about the relationship to Modified Julian Dates. Thanks Carsten, for the useful feedback, as always!
It’s my sense that the spec is now ready for working group last call in the CBOR Working Group.
The specification is available at:
An HTML-formatted version is also available at:
I’ve published updated SecEvent delivery specs addressing the directorate reviews received during IETF last call. Thanks to Joe Clarke, Vijay Gurbani, Mark Nottingham, Robert Sparks, and Valery Smyslov for your useful reviews.
The specifications are available at:
HTML-formatted versions are also available at:
IANA 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.
I was pleased by the quality of the discussions and participation at the first OpenID Foundation Virtual Workshop. There were over 50 participants, with useful conversations happening both on the audio channel and in the chat. Topics included current work in the working groups, such as eKYC-IDA, FAPI, MODRNA, FastFed, Shared Signals and Events, and OpenID Connect), OpenID Certification, and a discussion on interactions between browser privacy developments and federated login. Thanks to all who participated!
Here’s my presentation on the OpenID Connect working group and OpenID Certification: (PowerPoint) (PDF).
Update: The presentations from the workshop are available at OIDF Virtual Workshop — May 21, 2020.
This 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:
The IETF CBOR working group has adopted the specification Concise Binary Object Representation (CBOR) Tags for Date. The abstract of the specification is:
The Concise Binary Object Representation (CBOR, 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 (RFC 3339 date/time string) and tag 1 (Posix “seconds since the epoch”). Since then, additional requirements have become known. This specification defines a CBOR tag for an RFC 3339 date text string, for applications needing a textual date representation without a time. It also defines a CBOR tag for days since the Posix epoch, for applications needing a numeric date representation without a time. It is intended as the reference document for the IANA registration of the CBOR tags defined.
The need for this arose for the ISO Mobile Driver’s License specification in the working group ISO/IEC JTC 1/SC 17 “Cards and security devices for personal identification”.
The specification is available at:
An HTML-formatted version is also available at:
A number of refinements have been applied to the DPoP specification. As recorded in the History entries, they are:
Thanks to Brian Campbell for doing the editing for this round.
The specification is available at:
The two Security Event Token (SET) delivery specifications have been updated to address additional Area Director review comments by Benjamin Kaduk. See the History entries for descriptions of the changes, none of which were breaking. Both documents are now open for IETF Last Call reviews.
Thanks again to Ben for his thorough reviews. And thanks to Annabelle Backman for doing the editing for this round.
The specifications are available at:
HTML-formatted versions are also available at:
I gave the following invited “101” session presentation at the 30th Internet Identity Workshop (IIW) on Tuesday, April 28, 2020:
I missed being able to gauge audience reactions by looking around the room but the virtualized session was still well attended by a good group of people, who let me know how OpenID Connect is relevant to what they’re doing.
We’re making progress on a simple application-level proof-of-possession solution for OAuth 2.0. I’m pleased to report that DPoP has now been adopted as an OAuth working group specification. The abstract of the specification is:
This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.
The specification is available at:
Powered by WordPress & Theme by Anders Norén