Musings on Digital Identity

Author: Mike Jones Page 2 of 33

Building the Internet's missing identity layer

Invited OpenID Federation Presentation at 2024 FIM4R Workshop

OpenID logoThe OpenID Federation editors were invited to give a presentation on OpenID Federation at the 18th FIM4R Workshop, which was held at the 2024 TIIME Unconference. Giuseppe De Marco, Roland Hedberg, John Bradley, and I tag-teamed the presentation, with Vladimir Dzhuvinov also participating in the Q&A. Topics covered included motivations, architecture, design decisions, capabilities, use cases, history, status, implementations, and people.

Here’s the material we used:

It was the perfect audience – chock full of people with practical federation deployment experience!

Fully-Specified Algorithms adopted by JOSE working group

IETF logoThe “Fully-Specified Algorithms for JOSE and COSE” specification has been adopted by the JOSE working group. See my original post about the spec for why fully-specified algorithms matter. Thanks to all who supported adoption and also thanks to those who provided useful detailed feedback that we can address in future working group drafts.

The specification is available at:

OAuth 2.0 Protected Resource Metadata draft addressing all known issues

OAuth logoAaron Parecki and I have published a draft of the “OAuth 2.0 Protected Resource Metadata” specification that addresses all the issues that we’re aware of. In particular, the updates address the comments received during the discussions at IETF 118. As described in the History entry for -02, the changes were:

  • Switched from concatenating .well-known to the end of the resource identifier to inserting it between the host and path components of it.
  • Have WWW-Authenticate return resource_metadata rather than resource.

The specification is available at:

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

2024 OpenID Foundation Board Election Results

OpenID logoThanks to those of you who elected me to a two-year term on the OpenID Foundation board of directors. This is an incredibly exciting time for the OpenID Foundation and for digital identity, and I’m thrilled to be able to contribute via the OpenID board. Thanks for placing your trust in me!

I’d like to also take this opportunity to congratulate my fellow board members who were also elected: George Fletcher, Atul Tulshibagwale, and Mark Verstege. See the OpenID Foundation’s announcement of the 2024 election results.

My candidate statement was:


I am on a mission to build the Internet’s missing identity layer. OpenID specifications and initiatives are key to realizing that vision.

Widespread deployment of OpenID specifications has the potential to make people’s online interactions more seamless, secure, and valuable. I have been actively working since 2007 to make that an everyday reality.

2024 has huge potential for advances in digital identity. People are starting to have identity wallets holding digital credentials that they control. National and international federations are being established. Open Banking and Open Finance deployments are ongoing. Adoption of OpenID Connect (which we created a decade ago!) continues going strong. We’re on track to have OpenID Connect be published as ISO standards. OpenID specifications and programs are essential to all these outcomes.

While many of you know me and my work, here’s a few highlights of my contributions to the digital identity space and the OpenID community:

– I was primary editor of OpenID Connect, primary editor of the OAuth 2.0 bearer token specification [RFC 6750], and primary editor of the JSON Web Token (JWT) specification [RFC 7519] and the JSON Object Signing and Encryption (JOSE) specifications [RFCs 7515-7518], which are used by OpenID Connect. I was an editor of the Security Event Token specification [RFC 8417], which is used by Shared Signals and OpenID Connect. I’m an editor of the SIOPv2 specification and a contributor to the other OpenID for Verifiable Credentials specifications. I’m an editor of the OpenID Federation specification. The OAuth DPoP specification [RFC 9449] was my latest RFC. I’m an author of 32 RFCs and 17 final OpenID specifications, with more of each in the pipeline.

– I spearheaded creation of the successful OpenID Connect certification program and continue actively contributing to its success. Over 2,800 certifications have been performed and the pace keeps increasing! Certification furthers the Foundation’s goals of promoting interoperation and increasing the quality of implementations. It’s also become an important revenue stream for the Foundation.

– My contributions to the Foundation have included serving on the board since 2008, serving as board secretary during most of my tenure. I’ve helped organize numerous OpenID summits and working group meetings and regularly present there. I chaired the election committee that developed the Foundation’s election procedures and software. I co-chaired the local chapters committee that developed the policies governing the relationships with local OpenID chapters around the world. I serve on the liaison committee, facilitating our cooperation with other organizations. And way back in 2007, I worked with the community to create the legal framework for the OpenID Foundation, enabling both individuals and corporations to be full participants in developing OpenID specifications and ensuring that they can be freely used by all.

I’d like to continue serving on the OpenID board, because while the OpenID community is having notable successes, our work is far from done. Taking it to the next level will involve both additional specifications work and strategic initiatives by the Foundation. We need to continue building a broad base of supporters and deployers of OpenID specifications around the world. We need to continue fostering close working relationships with partner organizations. And we need to continue safeguarding OpenID’s intellectual property and trademarks, so they remain freely available for all to use.

I have a demonstrated track record of energetically serving the OpenID community and producing results that people actually use. I plan to continue taking an active role in making open identity solutions even more successful and ubiquitous. That’s why I’m running for a community board seat in 2024.

Mike Jones
michael_b_jones@hotmail.com
Blog: https://self-issued.info/
Professional Website: https://self-issued.consulting/

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!

On the journey to an Implementer’s Draft: OpenID Federation draft 31 published

OpenID logoOpenID Federation draft 31 has been published at https://openid.net/specs/openid-federation-1_0-31.html and https://openid.net/specs/openid-federation-1_0.html. It’s the result of concerted efforts to make the specification straightforward to read, understand, and implement for developers. Many sections have been rewritten and simplified. Some content has been reorganized to make its structure and relationships more approachable. Many inconsistencies were addressed.

Some inconsistencies fixed resulted in a small number of breaking changes. For instance, the name “trust_mark_owners” is now consistently used throughout, whereas an alternate spelling was formerly also used. The editors tried to make all known such changes in this version, so hopefully this will be the last set of breaking changes. We published draft 31 now in part to get these changes out to implementers. See the history entries at https://openid.net/specs/openid-federation-1_0-31.html#name-document-history for a detailed description of the changes made.

A comprehensive review of the specification is still ongoing. Expect more improvements in the exposition in draft 32. With any luck, -32 will be the basis of the next proposed Implementer’s Draft.

We’re definitely grateful for all the useful feedback we’re receiving from developers. Developer feedback is gold!

Hybrid Public Key Encryption (HPKE) for JOSE

IETF logoThe new “Use of Hybrid Public-Key Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)” specification has been published. Its abstract is:

This specification defines Hybrid public-key encryption (HPKE) for use with Javascript Object Signing and Encryption (JOSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key.

HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in JOSE is provided by JOSE-native security mechanisms or by one of the authenticated variants of HPKE.

This document defines the use of the HPKE with JOSE.

Hybrid Public Key Encryption (HPKE) is defined by RFC 9180. There’s a whole new generation of specifications using it for encryption. The Messaging Layer Security (MLS) Protocol [RFC 9420] uses it. TLS Encrypted Client Hello uses it. Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) brings it to COSE. And this specification brings it to JOSE.

One of our goals for the JOSE HPKE specification is to keep it closely aligned with the COSE HPKE specification. That should be facilitated by having multiple authors in common, with Hannes Tschofenig and Orie Steele being authors of both, and me being a COSE co-chair.

Aritra Banerjee will be presenting the draft to the JOSE working group at IETF 118 in Prague. I’m hoping to see many of you there!

The specification is available at:

On the Closing Stretch for Errata Corrections to OpenID Connect

OpenID logoThe initial OpenID Connect specifications became final on February 25, 2014. While the working group is rightfully proud of the quality of the work and the widespread adoption it has attained, specification writing is a human endeavor and mistakes will inevitably be made. That’s why the OpenID Foundation has a process for publishing Errata corrections to specifications.

Eight issues were identified and corrected that year, with the first set of errata corrections being published on November 8, 2014. Since that time, suggestions for improvements have continued to trickle in, but with a 9+ year trickle, a total of 95 errata issues have been filed! They range from the nearly trivial, such as an instance of http that should have been https, to the more consequential, such as language that could be interpreted in different ways.

I’m pleased to report that, with a substantial investment by the working group, I’ve managed to work through all the 87 additional errata issues filed since the first errata set and incorporate corrections for them into published specification drafts. They are currently undergoing OpenID Foundation-wide review in preparation for a vote to approve the second set of errata corrections.

As a bonus, the OpenID Foundation plans to submit the newly minted corrected drafts for publication by ISO as Publicly Available Specifications. This should foster even broader adoption of OpenID Connect by enabling deployments in some jurisdictions around the world that have legal requirements to use specifications from standards bodies recognized by international treaties, of which ISO is one. Just in time for OpenID Connect’s 10th anniversary!

OpenID Summit Tokyo 2024 and the 10th Anniversary of OpenID Connect

OpenID logoI’m pleased to bring your attention to the upcoming OpenID Summit Tokyo 2024, which will be held on Friday, January 19, 2024. Join us there for a stellar line-up of speakers and consequential conversations!

OpenID Summit Tokyo 2024

This builds on the successes of past summits organized by the OpenID Foundation Japan. For instance, I found the OpenID Summit Tokyo 2020 and associated activities and discussions both very useful and very enjoyable.

A special feature of the 2024 summit will be celebrating the 10th anniversary of the OpenID Connect specifications, which were approved on February 25, 2014. Speakers who were there for its creation, interop testing, and early deployments will share their experiences and lessons learned, including several key participants from Japan. As I recounted at EIC 2023, building ecosystems is hard. And yet we achieved that for OpenID Connect! We are working to create new identity ecosystems as we speak. I believe that the lessons learned from OpenID Connect are very applicable today. Come join the conversation!

Finally, as a teaser, I’m also helping the OpenID Foundation to plan two additional 10th anniversary celebrations at prominent 2024 identity events – one in Europe and one in the Americas. Watch this space for further news about these as it develops!

BLS Key Representations for JOSE and COSE updated for IETF 118

IETF logoTobias Looker and I have published an updated Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE specification in preparation for IETF 118 in Prague. This one of suite of IETF and IRTF specifications, including BLS Signatures and JSON Web Proofs that are coming together to enable standards for the use of JSON-based and CBOR-based tokens utilizing zero-knowledge proofs.

The specification is available at:

CBOR Web Token (CWT) Claims in COSE Headers Draft Addressing IETF Last Call Comments

IETF logoTobias Looker and I have published an updated CBOR Web Token (CWT) Claims in COSE Headers specification that addresses the IETF Last Call (WGLC) comments received. Changes made were:

  • Added Privacy Consideration about unencrypted claims in header parameters.
  • Added Security Consideration about detached content.
  • Added Security Consideration about claims that are present both in the payload and the header of a CWT.
  • Changed requested IANA COSE Header Parameter assignment number from 13 to 15 due to subsequent assignments of 13 and 14.
  • Acknowledged last call reviewers.

The specification is available at:

The specification is scheduled for the IESG telechat on November 30, 2023.

JSON Web Proofs specifications updated in preparation for IETF 118

IETF logoDavid Waite and I have updated the “JSON Web Proof”, “JSON Proof Algorithms”, and “JSON Proof Token” specifications in preparation for presentation and discussions in the JOSE working group at IETF 118 in Prague. The primary updates were to align the BBS algorithm text and examples with the current CFRG BBS Signature Scheme draft. We also applied improvements suggested by Brent Zundel and Alberto Solavagione.

The specifications are available at:

Thanks to David Waite for doing the heavy lifting to update the BBS content. Thanks to MATTR for publishing their Pairing Cryptography software, which was used to generate the examples. And thanks to Alberto Solavagione for validating the specifications with his implementation.

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:

Fully-Specified Algorithms updated in preparation for IETF 118

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” 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. Specifically, this draft adds descriptions of key representations and of algorithms not updated by the specification. See my original post about the spec for why fully-specified algorithms matter.

Hopefully working group adoption will be considered by the JOSE working group during IETF 118.

The specification is available at:

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

IIW LogoI convened the session “What does Presentation Exchange do and what parts of it do we actually need?” this week at the Internet Identity Workshop (IIW) to continue the discussion started during two unconference sessions at the 2023 OAuth Security Workshop. I briefly summarized the discussions that occurred at OSW, then we had a vigorous discussion of our own.

Key points made were:

  • There appeared to be rough consensus in the room that Presentation Exchange (PE) is pretty complicated. People had differing opinions on whether the complexity is worth it.
  • A lot of the complexity of PE comes from being able to request multiple credentials at once and to express alternatives.
  • Ultimately, the verifier knows what kinds of credentials it needs and the relationships between them. PE tries to let the verifier express some of that to the wallet.
  • Code running in the verifier making choices about the credentials it needs will always be more powerful than PE, because it has the full decision-making facilities of programming languages – including loops, conditionals, etc.
  • Making a composite request for multiple credentials can have a better UX than a sequence of requests. In some situations, the sequence could result in the person having to scan multiple QR codes. There may be ways to avoid that, while still having a sequence of requests.
  • Some said that they need the ability to request multiple credentials at once.
  • Brent Zundel (a PE author) suggested that while wallets could implement all of PE, verifiers could implement only the parts they need.
  • Not many parties had implemented all of PE. Torsten Lodderstedt suggested that we need feedback from developers.
  • We could create a profile of PE, reducing what implementers have to build and correspondingly reducing its expressive power.

The slides used to summarize the preceding discussions are available as PowerPoint and PDF. There are detailed notes capturing some of the back-and-forth at IIW with attribution.

Thanks to everyone who participated for an informative and useful discussion. My goal was to help inform the profiling and deployment choices ahead of us.

P.S. Since Thursday’s discussion, it occurred to me that a question I wish I’d asked is:

  • When a verifier needs multiple credentials, they may be in different wallets. If the verifier tries to make a PE request for multiple credentials that are spread between wallets, will it always fail because no single wallet can satisfy it?

Fodder for the next discussion…

OpenID Presentations at October 2023 OpenID Workshop and IIW

OpenID logoI gave the following presentation at the Monday, October 9, 2023 OpenID Workshop at CISCO:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 10, 2023:

Public Drafts of Third W3C WebAuthn and FIDO2 CTAP Specifications

W3C logoFIDO logoThe W3C WebAuthn and FIDO2 working groups have been actively creating third versions of the W3C Web Authentication (WebAuthn) and FIDO2 Client to Authenticator Protocol (CTAP) specifications. While remaining compatible with the original and second standards, these third versions add features that have been motivated by experience with deployments of the previous versions. Additions include Cross-Origin Authentication within an iFrame, Credential Backup State, the isPasskeyPlatformAuthenticatorAvailable method, Conditional Mediation, Device-Bound Public Keys (since renamed Supplemental Public Keys), requesting Attestations during authenticatorGetAssertion, the Pseudo-Random Function (PRF) extension, the Hybrid Transport, and Third-Party Payment Authentication.

I often tell people that I use my blog as my external memory. I thought I’d post references to these drafts to help me and others find them. They are:

Thanks to John Bradley for helping me compile the list of deltas!

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?

Page 2 of 33

Powered by WordPress & Theme by Anders Norén