Musings on Digital Identity

Category: OAuth Page 1 of 11

OAuth 2.0 Protected Resource Metadata Specification in RFC Editor Queue

OAuth logoI’m pleased to report that the “OAuth 2.0 Protected Resource Metadata” specification has been approved by the IESG and is now in the RFC Editor queue.

The version approved by the IESG and sent to the RFC Editor is:

It joins OAuth 2.0 Security Best Current Practice and JWT Response for OAuth Token Introspection, which are also both currently there.

Thanks to the IETF directorate reviewers and IESG members for their feedback that resulted in improvements to the specification!

OAuth 2.0 Protected Resource Metadata draft addressing reviews since IETF Last Call

OAuth logoAaron Parecki and I published a new version the “OAuth 2.0 Protected Resource Metadata” specification that addresses the review comments received since the IETF Last Call. Per the history entries, the changes were:

  • Added metadata values declaring support for DPoP and mutual-TLS client certificate-bound access tokens.
  • Added missing word caught during IANA review.
  • Addressed ART, SecDir, and OpsDir review comments by Arnt Gulbrandsen, David Mandelberg, and Bo Wu, resulting in the following changes:
  • Added step numbers to sequence diagram.
  • Defined meaning of omitting bearer_methods_supported metadata parameter.
  • Added internationalization of human-readable metadata values using the mechanism from [RFC7591].
  • Added resource_name metadata parameter, paralleling client_name in [RFC7591].
  • Added Security Considerations section on metadata caching.
  • Used and referenced Resource Identifier definition.
  • Added motivating example of an email client to intro.

The specification is available at:

Fourth and Likely Last Implementer’s Draft of OpenID Federation Specification

OpenID logoThe OpenID Foundation has approved the Fourth Implementer’s Draft of the OpenID Federation Specification. This is a major step towards having the specification become final.

The previous Implementer’s Draft was in 2021. A lot has happened since then, largely motivated by feedback from actual implementations and deployments. Some highlights of progress made in the spec since then are:

  • Changed name from OpenID Connect Federation to OpenID Federation, since Federation can be used for trust establishment for any protocol (including OpenID Connect).
  • Introduced distinct Federation endpoints.
  • Clearly defined and consistently used the terms Entity Statement, Entity Configuration, and Subordinate Statement.
  • Clearly defined which claims can occur in which kinds of Entity Statements.
  • Clearly defined Entity Types and the Federation Entity entity type.
  • Enhanced description of Trust Mark issuance and usage.
  • Defined relationship between metadata and metadata policy.
  • Clearly defined interactions between policy operators.
  • Defined where constraints may occur.
  • Tightened descriptions of Automatic Registration and Explicit Registration.
  • Added Historical Keys.
  • Defined and used trust_chain JWS Header Parameter.
  • Allowed Trust Chains to start with non-Trust Anchors.
  • Clarified use of client authentication.
  • Used OAuth Protected Resource Metadata.
  • Consistent error handling.
  • Added General-Purpose JWT Claims section.
  • Comprehensive use of content types and media types.
  • IANA registration of parameters, claims, and media types.
  • Added and improved many diagrams.
  • Substantial rewrites for increased consistency and clarity.
  • Added Giuseppe De Marco and Vladimir Dzhuvinov as editors.

As a preview of coming attractions, I’ll note that profiles of OpenID Federation are being written describing how it being used in wallet ecosystems and how it is being used in open finance ecosystems. And we’re creating a list of implementations. Watch this space for future announcements.

Special thanks to all the implementers and deployers who provided feedback to get us to this point!

OAuth 2.0 Protected Resource Metadata draft addressing shepherd comments

OAuth logoThe “OAuth 2.0 Protected Resource Metadata” specification has been updated to address feedback from our document shepherd Rifaat Shekh-Yusef in advance of IETF 120 in Vancouver. All changes were strictly editorial.

The specification is available at:

Celebrating Ten Years of OpenID Connect at Identiverse and EIC

EIC 2024 LogoIdentiverse LogoWe held the second and third of the three planned tenth anniversary celebrations for the completion of OpenID Connect at the 2024 Identiverse conference and European Identity and Cloud Conference. That concludes celebrations in Asia, the Americas, and Europe!

At both Identiverse and EIC, panelists included Nat Sakimura, John Bradley, and myself. Chuck Mortimore joined us at Identiverse. And Torsten Lodderstedt added his perspectives at EIC. We shared our perspectives on what led to OpenID Connect, why it succeeded, and what lessons we learned along the way.

The most common refrain throughout our descriptions was the design philosophy to “Keep simple things simple”. This was followed closely by the importance of early feedback from developers and deployers.

Chuck reached back in time to his OpenID slides from 2011. He reflected on what he was thinking at the time versus what actually happened (and why). Torsten pointed out the importance of cooperation, certification, security analysis, open standards, and an approachable community. At Identiverse, Nat reached back 25 years, examining the intellectual underpinnings and history of OpenID. And at EIC, Nat tackled assertions that OpenID Connect can be complex. John concluded by observing that the OpenID idea is greater than any particular specification.

Our recent OpenID Connect 10th anniversary sessions were:

They build upon the celebration at the OpenID Summit Tokyo 2024.

Thanks to the organizers of all these events for sponsoring the celebrations!

Standards are About Making Choices

EIC 2024 LogoI was honored to give the keynote presentation Standards are About Making Choices at the 2024 European Identity and Cloud Conference (PowerPoint) (PDF). The abstract was:

When building machines, we take for granted being able to use nuts, bolts, wires, light bulbs, and countless other parts made to industry standards. Standards contain choices about dimensions of screw threads, nut sizes, etc., enabling a marketplace of interoperable parts from multiple suppliers. Without these choices, every part would be custom manufactured. The same is true of the identity and security standards we use to build identity systems.

However, the identity and security standards at our disposal differ wildly in the degree to which they do and don’t make choices. Some consistently define ONE way to do things, resulting in everyone doing it that way (interoperability!). Others leave critical choices unmade, passing the buck to implementers and applications (your mileage may vary).

In this talk, I’ll name names and take prisoners, critiquing existing and emerging standards through the lens of the choices they made and failed to make. Hold on to your hats as we examine the pros and cons of the choices made by OAuth, SAML, X.509, OpenID Connect, Verifiable Credentials, DIDs, WebCrypto, JOSE, COSE, and many others through this lens!

I believe you’ll agree with me that making choices matters.

The conference keynote description includes a recording of the presentation.

Thanks to MATTR for providing a designer to work with me on the presentation, enabling the visual design to transcend my usual black-text-on-white-background design style!

Using Standards: Some Assembly Required

Identiverse LogoI gave the following presentation in the session Using Standards: Some Assembly Required at the 2024 Identiverse conference (PowerPoint) (PDF). The abstract was:

  • Standards are about making choices. When building machines, we take for granted being able to use nuts, bolts, wires, light bulbs, and countless other parts made to industry standards. Standards contain choices about dimensions of screw threads, nut sizes, etc., enabling a marketplace of interoperable parts from multiple suppliers. Without these choices, every part would be custom-manufactured. The same is true of the identity and security standards we use to build the Identity Engine. However, the identity and security standards at our disposal differ wildly in the degree to which they do and don’t make choices. Some consistently define ONE way to do things, resulting in everyone doing it that way (interoperability!). Others leave critical choices unmade, passing the buck to implementers and applications (your mileage may vary). In this talk, I’ll name names and take prisoners, critiquing existing and emerging standards through the lens of the choices they made and failed to make. Hold on to your hats as we examine the pros and cons of the choices made by OAuth, SAML, X.509, OpenID Connect, Verifiable Credentials, DIDs, WebCrypto, JOSE, COSE, and many others through this lens! I believe you’ll agree with me that making choices matters.

The audience was highly engaged by the process of giving existing and emerging standards letter grades based on the choices they made (or failed to make)!

Celebrating Ten Years of OpenID Connect at the OpenID Summit Tokyo 2024

OpenID logoWe held the first of three planned tenth anniversary celebrations for the completion of OpenID Connect at the OpenID Summit Tokyo 2024. The four panelists were Nov Matake, Ryo Ito, Nat Sakimura, and myself. We shared our perspectives on what led to OpenID Connect, why it succeeded, and what lessons we learned along the way.

The most common refrain throughout our descriptions was the design philosophy to “Keep simple things simple”. I believe that three of the four of us cited it.

I recounted that we even had a thought experiment used to make the “Keep simple things simple” principle actionable in real time: the “Nov Matake Test”. As we considered new features, we’d ask ourselves “Would Nov want to add it to his implementation?” And “Is it simple enough that he could build it in a few hours?”

The other common thread was the criticality of interop testing and certification. We held five rounds of interop testing before finishing the specifications, with the specs being refined after each round based on the feedback received. The early developer feedback was priceless – much of it from Japan!

Our OpenID Connect 10th anniversary presentations were:

Thanks to the OpenID Foundation Japan for the thought-provoking and enjoyable OpenID Summit Tokyo 2024!

Panel in Tokyo

The Nov Matake Test

25 Years of OpenID

There Came Mike Jones

Ten Years of OpenID Connect and Looking to the Future

OpenID logoTen years ago today the drafts that would be approved as the final OpenID Connect specifications were published, as announced in my post Fourth and possibly last Release Candidates for final OpenID Connect specifications and Notice of 24 hour review period.

The adoption of OpenID Connect has exceeded our wildest expectations. The vast majority of federated signins to sites and applications today use OpenID Connect. Android, AOL, Apple, AT&T, Auth0, Deutsche Telekom, ForgeRock, Google, GrabTaxi, GSMA Mobile Connect, IBM, KDDI, Microsoft, NEC, NRI, NTT, Okta, Oracle, Orange, Ping Identity, Red Hat, Salesforce, Softbank, Symantec, T-Mobile, Telefónica, Verizon, Yahoo, and Yahoo! Japan, all use OpenID Connect, and that’s just the tip of the iceberg. While OpenID Connect is “plumbing” and not a consumer brand, it’s filling a need and doing it well.

It’s fitting that the second set of errata corrections to the OpenID Connect specifications were just approved, as described in the post Second Errata Set for OpenID Connect Specifications Approved. While we are proud of the quality of the final specifications, with 9 3/4 years of thousands of developers using and deploying the specifications, it’s unsurprising that issues would be found that needed clarification and correction.

The updated OpenID Connect specifications have just been submitted to the International Organization for Standardization (ISO) for Publicly Available Submission (PAS) status. Approved PAS submissions are published as ISO specifications. This will foster adoption in jurisdictions that require using standards that are published by organizations with international treaty status.

Celebrations of the tenth anniversary of the approval of OpenID Connect will occur worldwide in 2024. The first will be in Asia at the OpenID Summit Tokyo in January. The second will be in the Americas at Identiverse in May. The third will be in Europe at the European Identity and Cloud Conference in June. Join us at these events for the celebrations!

I can’t wait to see what the next decade brings for OpenID Connect!

OAuth 2.0 Protected Resource Metadata updated in preparation for IETF 118

OAuth logoAaron Parecki and I have updated the “OAuth 2.0 Protected Resource Metadata” specification in preparation for presentation and discussions at IETF 118 in Prague. The updates address comments received during the discussions at IETF 117 and afterwards. As described in the History entry, the changes were:

  • Renamed scopes_provided to scopes_supported
  • Added security consideration for scopes_supported
  • Use BCP 195 for TLS recommendations
  • Clarified that resource metadata can be used by clients and authorization servers
  • Added security consideration recommending audience-restricted access tokens
  • Mention FAPI Message Signing as a use case for publishing signing keys
  • Updated references

The specification is available at:

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is now RFC 9449

OAuth logoThe OAuth 2.0 Demonstrating Proof of Possession (DPoP) specification has been published as RFC 9449! As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The concise abstract says it all:

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.

As I described in my 2022 Identiverse presentation on DPoP it’s been a Long and Winding Road to get here. Efforts at providing practical proof of possession protection for tokens have included:

  • SAML 2.0 Holder-of-Key Assertion Profile – Not exactly OAuth
  • OAuth 1.0 used PoP – But message signing too complicated
  • OAuth 2.0 MAC draft – Used similarly complicated signing
  • OAuth 2.0 HTTP Signing draft – Abandoned due to complexity
  • TLS Token Binding – Some browsers declined to ship it
  • OAuth 2.0 Mutual TLS – Client certs notoriously difficult to use
  • OAuth 2.0 DPoP – Today’s RFC aimed at simply and practically solving this important problem

As they say, I think this one’s the one! Implement, deploy, and enjoy!

Adoption Time! And Lessons Learned…

IETF logoI’ve had two different IETF specifications adopted by two different working groups in the last two days – a pleasant coincidence! Yesterday, the COSE “typ” (type) Header Parameter specification was adopted by the COSE working group. Today, the OAuth 2.0 Protected Resource Metadata specification was adopted by the OAuth working group. Their journeys from individual drafts to working group drafts couldn’t have been more different!

As I was musing with Phil Hunt, who wrote the original individual draft of OAuth 2.0 Protected Resource Metadata with me, I’m pretty sure that this is the longest time from writing an individual draft to it becoming a working group draft in my experience: August 3, 2016 to September 6, 2023 – seven years and a month!

Whereas, the time from the individual draft of COSE “typ” (type) Header Parameter to the first working group draft was only three months: July 8, 2023 to September 5, 2023. Which got me thinking… Is that the fastest progression I’ve had?

It turns out that my fastest time from individual draft to working group draft was for the JWK Thumbprint URI specification which I wrote with Kristina Yasuda. It went from individual draft to working group draft in only two months: November 24, 2021 to January 28, 2022. (And it became RFC 9278 on August 9, 2022 – less than nine months from start to finish, which I believe is also a personal record.)

Ironically, while OAuth 2.0 Protected Resource Metadata took over seven years from individual to working group drafts, a closely-related draft, OAuth 2.0 Discovery (which became RFC 8414) was previously my fastest from individual draft to working group draft: 2.5 months! (The journey to becoming an RFC took 2.5 years.)

The other relative speed demon was Proof-Of-Possession Semantics for JSON Web Tokens (JWTs): 3.5 months from individual draft to working group draft and two years from start to RFC 7800.


What are my takeaways from all these musings about starting things?

The Key Is Not Enough! – OpenID Connect Federation at OSW 2023

OAuth Security WorkshopVladimir Dzhuvinov gave the innovative and informative presentation “The Key Is Not Enough!” on OpenID Connect Federation at the 2023 OAuth Security Workshop in London. This action thriller of a presentation covers history, goals, mechanisms, status, deployments, and possible futures of the work. The comparisons between X.509 certificates and Federation Trust Infrastructure are particularly enlightening!

What does Presentation Exchange do and what parts of it do we actually need?

OAuth Security WorkshopI organized unconference sessions on Wednesday and Thursday at the 2023 OAuth Security Workshop on “What does Presentation Exchange do and what parts of it do we actually need?”. I facilitated primarily by creating an inventory features for discussion in advance, which you’ll find on slide 3. Notes from Wednesday’s session are on slide 4. Thursday we discussed functionality needed and not needed for presenting Verifiable Credentials (with the feature realizations not necessarily tied to Presentation Exchange), which you can find on slide 5. Notes from Thursday’s discussion are on the final two pages.

Thanks to everyone who participated for a great discussion. I think we all learned things!

The slides used as an interactive notepad during our discussions are available as PowerPoint and PDF.

OAuth 2.0 Protected Resource Metadata now with WWW-Authenticate

OAuth logoIn collaboration with Aaron Parecki, the ability for OAuth 2.0 protected resource servers to return their resource identifiers via WWW-Authenticate has been added to the OAuth 2.0 Protected Resource Metadata specification. This enables clients to dynamically learn about and use protected resources they may have no prior knowledge of, including learning what authorization servers can be used with them.

This incorporates functionality originally incubated in draft-parecki-oauth-authorization-server-discovery-00. Aaron and I had been asked to merge the functionality of our two drafts during an OAuth working group session at IETF 116. We’re both happy with the result!

The specification is available at:

Touchstones Along My Identity Journey

EIC 2023 LogoI had the distinct honor of being invited to give a keynote talk at EIC 2023. The result was Touchstones Along My Identity Journey. My talk abstract was:

In 2005, Kim Cameron excitedly told me about digital identity and set my life on a course to “Build the Internet’s missing identity layer”. In this talk I’ll tell key stories from my identity journey — stories of the people, ideas, and lessons learned along the way. I’ll speak of technology and collaboration, usability and business models, solving problems people actually have, and building new ecosystems. Come with me on this journey of exploration, trials, triumphs, and humor as I recount touchstones of the human endeavor that is digital identity.

Kuppinger Cole has posted a video of my keynote on YouTube. I was pleased with how well it went. After the first few sentences, I was in the zone! I hope many of you find the messages in the talk useful.

My slides are also available in (PowerPoint) and PDF.

Special thanks go to the OpenID Foundation for supporting my trip to EIC this year and to designer Alistair Kincaid at MATTR for helping me transcend my usual black-bulleted-text-on-a-white-background presentation style!

EIC 2023 Keynote Photo

EIC 2023 Keynote Photo with Kim Cameron

EIC 2023 Keynote Photo for OAuth

OAuth DPoP specification is in the hands of the RFC Editor

OAuth logoThe OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) specification was approved by the IESG and is now in the hands of the RFC Editor in preparation for publication as an RFC. In a related development, the multiple IANA registrations requested by the specification are already in place.

As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The latest version of the specification is available at:

Implement and deploy early and often!

OAuth DPoP Nearing Completion

OAuth logoFollowing the IETF-wide publication request, we’ve published another DPoP draft that addresses additional review comments received to date. This version is destined for the IESG Telechat on April 13, 2023.

Recent changes as described in the history log are:

  • Add sec considerations sub-section about binding to client identity
  • Explicitly say that nonces must be unpredictable
  • Change to a numbered list in ‘Checking DPoP Proofs’
  • Editorial adjustments
  • Incorporated HTTP header field definition and RFC 8792 ‘\’ line wrapping suggestions by Mark Nottingham

The specification is available at:

OAuth DPoP Specification Addressing Area Director Review Comments

OAuth logoThis week Brian Campbell published an updated OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft addressing the Area Director review comments received. Thanks to Roman Danyliw for his useful review!

As Brian wrote, updates in this version of the specifiation were:

  • Updates from Roman Danyliw’s AD review
  • DPoP-Nonce now included in HTTP header field registration request
  • Fixed section reference to URI Scheme-Based Normalization
  • Attempt to better describe the rationale for SHA-256 only and expectations for how hash algorithm agility would be achieved if needed in the future
  • Elaborate on the use of multiple WWW-Authenticate challenges by protected resources
  • Fix access token request examples that were missing a client_id

The specification is available at:

Publication Requested for OAuth DPoP Specification

OAuth logoBrian Campbell published an updated OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) draft addressing the shepherd review comments received. Thanks to Rifaat Shekh-Yusef for his useful review!

Following publication of this draft, Rifaat also created the shepherd write-up, obtained IPR commitments for the specification, and requested publication of the specification as an RFC. Thanks all for helping us reach this important milestone!

The specification is available at:

Page 1 of 11

Powered by WordPress & Theme by Anders Norén