I gave the following invited “101” session presentation at the 33rd Internet Identity Workshop (IIW) on Tuesday, October 12, 2021:
The session was well attended. There was a good discussion about the use of passwordless authentication with OpenID Connect.
The 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:
I gave the following presentation on the OpenID Connect Working Group during the September 13, 2021 OpenID Workshop at the 2021 European Identity and Cloud (EIC) conference. As I noted during the talk, this is an exciting time for OpenID Connect; there’s more happening now than at any time since the original OpenID Connect specs were created!
The 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!
The 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.
The 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!
I gave the following presentation on the OpenID Connect Working Group at the Third Virtual OpenID Workshop on Thursday, April 29, 2021:
Today marks an important milestone in the life of the OpenID Foundation and the worldwide digital identity community. Following Don Thibeau’s decade of exemplary service to the OpenID Foundation as its Executive Director, today we welcomed Gail Hodges as our new Executive Director.
Don was instrumental in the creation of OpenID Connect, the Open Identity Exchange, the OpenID Certification program, the Financial-grade API (FAPI), and its ongoing worldwide adoption. He’s created and nurtured numerous liaison relationships with organizations and initiatives advancing digital identity and user empowerment worldwide. And thankfully, Don intends to stay active in digital identity and the OpenID Foundation, including supporting Gail in her new role.
Gail’s Twitter motto is “Reinventing identity as a public good”, which I believe will be indicative of the directions in which she’ll help lead the OpenID Foundation. She has extensive leadership experience in both digital identity and international finance, as described in her LinkedIn profile. The board is thrilled to have her on board and looks forward to what we’ll accomplish together in this next exciting chapter of the OpenID Foundation!
I encourage all of you to come meet Gail at the OpenID Foundation Workshop tomorrow, where she’ll introduce herself to the OpenID community.
I gave the following invited “101” session presentation at the 32nd Internet Identity Workshop (IIW) on Tuesday, April 20, 2021:
The session was well attended. There was a good discussion about uses of Self-Issued OpenID Providers.
As 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:
The 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.
The FIDO Alliance has published this Public Review Draft for the FIDO2 Client to Authenticator Protocol (CTAP) specification, bringing the second version of FIDO2 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.
This parallels the similar progress of the closely related second version of the W3C Web Authentication (WebAuthn) specification, which recently achieved Proposed Recommendation (PR) status.
After 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:
The 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.
Are you registered for the Internet Identity Workshop (IIW) yet? As I wrote a decade, a year, and a day ago, “It’s where Internet identity work gets done.” That remains as true now is it was then!
As a personal testimonial, I wrote this to the IIW organizers after the 2020 IIWs:
“Thanks again for running the most engaging and successful virtual meetings of the year (by far!). While I’ve come to dread most of the large virtual meetings, IIW online remains true to the spirit of the last 15 years of useful workshops. Yes, I miss talking to Rich and the attendees in the coffee line and having impromptu discussions throughout, and we’ll get back to that in time, but the sessions remain useful and engaging.”
I’m also proud that Microsoft is continuing its 15-year tradition of sponsoring the workshop. Rather than buying dinner for the attendees (the conversations at the dinners were always fun!), we’re sponsoring scholarships for those that might otherwise not be able to attend, fostering an even more interesting and diverse set of viewpoints at the workshop.
I hope to see you there!
The 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!
The 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.
The 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. ;-)
Like the First OpenID Foundation Virtual Workshop, I was once again pleased by the usefulness of the discussions at the Second OpenID Foundation Virtual Workshop held today. Many leading identity engineers and businesspeople participated, with valuable conversations happening both via the voice channel and in the chat. Topics included current work in the working groups, such as eKYC-IDA, FAPI, MODRNA, FastFed, EAP, Shared Signals and Events, and OpenID Connect, plus OpenID Certification, OpenID Connect Federation, and Self-Issued OpenID Provider (SIOP) extensions.
Identity Standards team colleagues Kristina Yasuda and Tim Cappalli presented respectively on Self-Issued OpenID Provider (SIOP) extensions and Continuous Access Evaluation Protocol (CAEP) work. Here’s my presentation on the OpenID Connect working group (PowerPoint) (PDF) and the Enhanced Authentication Profile (EAP) (PowerPoint) (PDF) working group. I’ll add links to the other presentations when they’re posted.
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.
Powered by WordPress & Theme by Anders Norén