Mike Jones: self-issued

Musings on Digital Identity

Fully-Specified Algorithms are now the Law of the Land

By

On May 13, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoI’m thrilled to be able to report that, from now on, only fully-specified algorithms will be registered for JOSE and COSE. Furthermore, fully-specified signature algorithms are now registered to replace the previously registered polymorphic algorithms, which are now deprecated. For example, you can now use Ed25519 and Ed448 instead of the ambiguous EdDSA.

The new IANA JOSE registrations and IANA COSE registrations are now in place, as are the deprecations of the polymorphic signing algorithms. And perhaps most significantly for the long term, the instructions to the designated experts for both registries have been updated so that only fully-specified algorithms will be registered going forward.

Lots of people deserve credit for this significant improvement to both ecosystems. Filip Skokan was the canary in the coal mine, alerting the OpenID Connect working group to the problems with trying to sign with Ed25519 and Ed448 when there were no algorithm identifiers that could be used to specify their use. Similarly, John Bradley alerted the WebAuthn working group to the same problems for WebAuthn and FIDO2, devising the clever and awful workaround that, when used by those specs, EdDSA is to be interpreted as meaning Ed25519. John also supported this work as a JOSE working group chair. Roman Danyliw supported including the ability to specify the use of fully-specified algorithms in the JOSE charter as the Security Area Director then responsible for JOSE. Karen O’Donoghue created the shepherd write-up as JOSE co-chair. Deb Cooley thoroughly reviewed and facilitated advancement of the specification as the Security Area Director currently responsible for JOSE. And of course, Orie Steele, the co-inventor of the fully-specified algorithms idea, and my co-author since our audacious proposal to fix the polymorphic algorithms problem at IETF 117 in July 2023 deserves huge credit for making the proposal a reality!

The specification is now in the RFC Editor Queue. I can’t wait until it pops out the other side as an RFC!

The specification is available at:

Thanks to all who helped make fully-specified algorithms the law of the land!

So you want to use Digital Credentials? You’re now facing a myriad of choices!

By

On May 9, 2025

In CBOR, Claims, Events, Federation, IETF, Interoperability, JSON, OpenID, Privacy, Specifications

EIC 2025 LogoI gave the keynote talk So you want to use Digital Credentials? You’re now facing a myriad of choices! at EIC 2025. I opened by describing engineering choices – credential formats (W3C VCs, ISO mDOCs, SD-JWTs, SD-CWTs, JWPs, X.509 Certificates), issuance and presentation mechanisms (bespoke and standards-based, in-person and remote), mechanisms for choosing them (query languages, user interfaces), and trust establishment mechanisms (trust lists, certificates, and federation).

I then upped the ante by talking about the criticality of usability, the challenges of building ecosystems (something Andrew Nash first explained to me most of two decades ago!), and how digital credentials are not an end in and of themselves; they’re a tool to help us solve real-world problems. And of course, I closed by coming back to my theme Standards are About Making Choices, urging us to come together and make the right choices to enable interoperable use of digital credentials in ways that benefit people worldwide.

View my slides as PowerPoint or PDF. I’ll also post a link to the video of the presentation here once Kuppinger Cole posts it.

EIC 2025 Andrew Nash

Thought Experiment on Trust Establishment

Will people be able to use it and want to?

Standards Are About Making Choices

Thank You to SIROS

Mike Jones Candid

Fully-Specified Algorithms Specification Addressing IESG Feedback

By

On May 6, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to address feedback received through directorate reviews and from Internet Engineering Steering Group (IESG) members. This prepares us for consideration of the specification by the IESG during its “telechat” on Thursday. This is an important milestone towards progressing the specification to become an RFC.

Changes made since I last wrote about the spec, as summarized in the history entries, are:

-11

  • Stated in the abstract that the specification deprecates some polymorphic algorithm identifiers, as suggested by Éric Vyncke.

-10

  • Provided a complete list of the Recommended column terms for COSE registrations, as suggested by Mohamed Boucadair.
  • Applied suggestions to improve the exposition received during IESG review.

-09

  • Addressed comments from secdir review by Kathleen Moriarty.

-08

  • Updated requested Brainpool algorithm numbers to match those chosen by Sean Turner.
  • Incorporated wording suggestions by Vijay Gurbani.

The specification is available at:

Five Million Italian Digital Wallet Users

By

On May 1, 2025

In Federation, OpenID, Software, Specifications

OpenID logoMy friend Giuseppe De Marco shared the article “Documenti su IO: 5 milioni di attivazioni per IT-Wallet” with me about how five million people are now using the Italian digital wallet. It adds the information that 4.3 million health cards, 4 million driver’s licenses and 100,000 European Disability Cards have been issued to those wallets. These are significant accomplishments!

(Yes, the article is in Italian. ;-) I read it with the assistance of machine translation.)

These accomplishments are made possible through use of standards. Having just been at an OpenID Federation interop event in Stockholm, Sweden, I find it particularly timely that this is an example of five million people productively using OpenID Federation in their daily lives.

This article about the Italian Digital Wallet System is a good companion piece, providing insights into the goals of the Italian Digital Wallet project. I recommend them both!

Hybrid Public Key Encryption (HPKE) for JOSE incorporating feedback from IETF 122

By

On April 25, 2025

In Cryptography, IETF, JSON, Specifications

IETF logoThe “Use of Hybrid Public-Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)” specification has updated to incorporate feedback from IETF 122 in Bangkok.

Per the History entries, the changes were:

  • Use "enc":"int" for integrated encryption.
  • Described the reasons for excluding authenticated HPKE.
  • Stated that mutually known private information MAY be used as the HPKE info value.

At this point, the authors have closed all the issues and PRs that we believe there’s consensus to address. I would normally suggest that we’re ready for working group last call at this point, but I’d like us to take the extra step to verify that the spec is aligned with the COSE HPKE spec first. Both as an author of the JOSE HPKE spec and as a COSE chair interested in the COSE HPKE spec, I’d request that members of both working groups review the specs together and send their feedback.

OAuth 2.0 Protected Resource Metadata is now RFC 9728

By

On April 23, 2025

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Protected Resource Metadata specification has been published as RFC 9728! This is certainly the longest that any RFC that I have worked on has taken from initial individual draft to RFC – August 2016 to April 2025 – 8 years and 8 months. As we discussed at the 2025 OAuth Security Workshop in Reykjavík:

Timing can be fickle. What may not be useful at one time can turn out to be useful later.

Per the abstract, here’s what it adds to the OAuth 2.0 family of specifications:

This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource.

It joins the OAuth 2.0 Dynamic Client Registration Protocol [RFC 7591] and OAuth 2.0 Authorization Server Metadata [RFC 8414] specifications, completing the set of metadata specifications for all three OAuth 2.0 roles.

I’m glad to have co-authored this one with long-time collaborator Phil Hunt and new collaborator Aaron Parecki. And I’m proud of the fact that all of my last five RFCs had a co-author for which it was their first RFC; in this case, it’s Aaron’s first RFC.

Congratulations, Aaron! It was a pleasure working on this with you.

SPICEy Developments

By

On April 18, 2025

In CBOR, Claims, IETF, Specifications

IETF logoThis week saw several useful developments in the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. Two new drafts were adopted and an individual draft was published also intended for later adoption by the working group. Here’s the tour…

  • GLobal Unique Enterprise (GLUE) Identifiers was adopted. The specification’s abstract is:

    This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace.

    I worked closely with Brent Zundel on this one, primarily defining and using the IETF SPICE URN namespace, in which the GLUE namespace now resides.

  • OpenID Connect standard claims registration for CBOR Web Tokens was adopted. The specification’s abstract is:

    This document registers OpenID Connect standards claims already used in JSON Web Tokens for CBOR Web Tokens.

    While I didn’t work on this specification directly, I did suggest changes to the initial version to its author, Beltram Maldant, intended to make the spec ready for working group adoption, in my role as a Designated Expert for the IANA CBOR Web Token (CWT) Claims registry. I’m glad this is happening!

  • Traceability Claims was updated with an eye towards future working group adoption. The specification’s abstract is:

    This document defines claims to support traceability of physical goods across supply chains, focusing on items such as bills of lading, transport modes, and container manifests. These claims standardize the encoding of essential logistics and transport metadata, facilitating enhanced transparency and accountability in global supply chains. These claims are registered for use in both CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs).

    I worked closely with Mike Prorock on this one, primarily motivating and refining the claim definitions and registering JWT claims in addition to the corresponding CWT claims.

SPICEy indeed!

Finishing the OpenID Connect EAP ACR Values specification

By

On April 9, 2025

In OpenID, Phishing Resistance, Specifications

OpenID logoThe OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 specification has started its 60-day review to become an OpenID Final Specification. Recent steps leading up to this were:

The specification is glue that ties together OpenID Connect, W3C Web Authentication, and FIDO Authenticators, enabling them to be seamlessly used together.

The two ACR values defined by the specification are:

  • phr:
    Phishing-Resistant. An authentication mechanism where a party potentially under the control of the Relying Party cannot gain sufficient information to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User. (Note that the potentially malicious Relying Party controls where the User-Agent is redirected to and thus may not send it to the End User’s actual OpenID Provider). NOTE: These semantics are the same as those specified in [OpenID.PAPE].
  • phrh:
    Phishing-Resistant Hardware-Protected. An authentication mechanism meeting the requirements for phishing-resistant authentication above in which additionally information needed to be able to successfully authenticate to the End User’s OpenID Provider as if that party were the End User is held in a hardware-protected device or component.

The Phishing-Resistant definition dates back 2008!

For the record, the two XSD files that I wrote to get us here are:

OpenID Presentations at April 2025 OpenID Workshop and IIW

By

On April 9, 2025

In Events, OpenID

OpenID logoAs has become traditional, I gave the following presentation at the Monday, April 7, 2025 OpenID Workshop at Google:

I also gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, April 8, 2025:

A Significant Event Without Fanfare

By

On April 4, 2025

In OpenID, Specifications

OpenID logoA significant event in digital identity occurred without fanfare today. Presentation Exchange was removed from the OpenID for Verifiable Presentations specification. It had once-upon-a-time been the only query language used for verifiable credential presentation. In October 2024, the Digital Credential Query Language (DCQL) was added alongside it. Today, after much discussion by the working group, Presentation Exchange was removed, making DCQL the only query language supported. Importantly, this was done before OpenID4VP became a final specification.

Replacing Presentation Exchange (PE) has been a multi-year journey. I’ve been advocating for its replacement for years, including leading two sets of unconference discussions titled “What does Presentation Exchange do and what parts of it do we actually need?” – one in August 2023 at the OAuth Security Workshop and one in October 2023 at the Internet Identity Workshop. These discussions were intended to create awareness of the need to replace PE and start building consensus for its removal. Others also took this position early with me, including Tobias Looker and Oliver Terbu. Daniel Fett and Brian Campbell were receptive to the possibility early as well.

Removing a feature that people had taken a dependency on is not without pain. Numerous prototype wallets and verifiers used parts of it. But that’s the rub. There was so much there in Presentation Exchange that most implementations didn’t use most of it. As a result, interoperability, while possible, was a tricky and sometimes elusive target.

Presentation Exchange was ambitious in scope. It was a Swiss Army Knife of a specification. A goal was to enable complex queries for multiple credentials based on a general-purpose query language intended to be able to be used over credentials represented in JSON in any way. You could even include attributes of credentials other just their claims in the queries, such as algorithms and formats. You could ask for 2 of this or 3 of that and one or more of the following, as long as it is in format X, Y, or Z. It didn’t follow one of my guiding standards principles: “Keep simple things simple.” As a result, negative feedback from implementers grew over time.

Now we have a purpose-built query language designed for the task and protocol at hand. Is it as simple as it could be? No. Are all the features motivated by real-world non-hypothetical use cases? Yes.

The creation of DCQL was led by Daniel Fett. A precursor query language that helped inform DCQL was created by Oliver Terbu, Tobias Looker, and myself. Discussions at the Internet Identity Workshop informed what became DCQL, as did discussions at the IDUnion hackathon in Nürnberg in 2024 that included Kristina Yasuda, Christian Bormann, and Paul Bastian.

You can see OpenID4VP when PE was the only query language, when it had both query languages, and now with only DCQL. Compare for yourself.

Let me close by saying that I respect the people who created Presentation Exchange to a person. I count many of them as friends. They took a complex multi-faceted problem and wrapped their arms around it, producing a concrete solution. Much can be said in favor of those who pick up the pen and dare to create. Much was learned from what they produced, and it helped bootstrap an emerging industry. We wouldn’t be where we are today, were it not for their pioneering efforts!

In the end, the removal happened unceremoniously, with the merge of a pull request, like so many other changes – nearly anticlimactic. But this one marks a sea change in how credentials are presented. Thanks to all who made this happen!

I didn’t want to let the moment pass without recognizing its significance.

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

By

On March 18, 2025

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

FIDO logoThe FIDO Alliance has completed the CTAP 2.2 Specification. The closely-related third version of the W3C Web Authentication (WebAuthn) specification is also nearing final status; this WebAuthn Level 3 working draft is currently going through the review steps to become a W3C Recommendation.

So what’s new in the third versions?

Changes between CTAP 2.1 and CTAP 2.2 are:

Changes between WebAuthn Level 2 and the WebAuthn Level 3 working draft are described in the document’s Revision History.

Completing these V3 specifications represents important progress in our quest to free us from the password!

Fully-Specified Algorithms Specification Addressing Area Director Feedback

By

On March 7, 2025

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie Steele and I want to thank Deb Cooley for her Area Director review of the “Fully-Specified Algorithms for JOSE and COSE” specification. Addressing it simplified the exposition, while preserving the essence of what the draft accomplishes.

Specifically, the resulting draft significantly simplified the fully-specified encryption description and removed the appendix on polymorphic ECDH algorithms. We also stated that HSS-LMS is not fully specified, as suggested by John Preuß Mattsson.

The draft has now completed IETF last call, with the two resulting reviews stating that the draft is ready for publication.

The specification is available at:

COSE Algorithms for Two-Party Signing

By

On March 3, 2025

In CBOR, Cryptography, FIDO, IETF, Specifications, W3C

IETF logoEmil Lundberg and I have published the COSE Algorithms for Two-Party Signing specification. Its abstract is:

This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited-bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data.

A motivating use case for this is for WebAuthn/FIDO2 Authenticators to use when signing application data, as described in the proposed WebAuthn signing extension. Parts of this spec’s content were previously in the Asynchronous Remote Key Generation (ARKG) algorithm spec, which we’ve also been updated.

I plan to talk about the spec during IETF 122 in Bangkok. I hope to see many of you there!

The specification is available at:

This work was supported by the SIROS Foundation.

The Cambrian Explosion of OAuth and OpenID Specifications

By

On February 28, 2025

In Events, IETF, OAuth, OpenID, Specifications

OAuth Security WorkshopVladimir Dzhuvinov and I led a discussion on The Cambrian Explosion of OAuth and OpenID Specifications at the 2025 OAuth Security Workshop in Reykjavík.

The abstract for the session was:

The number of OAuth and OpenID specifications continues to grow. At present there are 30 OAuth RFCs, two more in the RFC Editor queue, 13 OAuth working group drafts, and another eight individual OAuth drafts that may advance. There are nine JOSE RFCs and seven working group drafts. There are four SecEvent RFCs. On the OpenID side, there are 12 final OpenID Connect specs, three final FAPI specs, one final MODRNA spec, three final eKYC-IDA specs, and 24 Implementer’s drafts across the OpenID working groups, plus another ten working group drafts.

The number of possible combinations boggles the mind. And there’s no end in sight!

What’s a developer to do? How have people and companies gone about selecting and curating the specs to implement in an attempt to create coherent and useful open source and commercial offerings? And faced with such an array of combinations and choices, how are application developers to make sense of it all? How can interoperability be achieved in the face of continued innovation?

This session will prime the pump by discussing choices made by some existing open source and commercial offerings in the OAuth and OpenID space and lead to an open discussion of choices made by the workshop attendees and the reasoning behind them. It’s our goal that useful strategies emerge from the discussion that help people grapple with the ever-expanding sets of specifications and make informed implementation choices, while still fostering the innovation and problem-solving that these specifications represent.

The slides used to queue up the discussion session are available as PowerPoint and PDF. Also, see the list of 101 OAuth and OpenID-related specifications referenced during the discussion.

The topic seems to have touched a chord. Many people were clearly already thinking about the situation and shared their views. Some of them were:

  • Nobody actually expects everyone to implement everything.
  • Stopping things is super hard. But sometimes it’s necessary (as Brian Campbell put it, “when they’re wrong”).
  • Timing can be fickle. What may not be useful at one time can turn out to be useful later.
  • Some specs are highly related and often used together. But those relationships are not always apparent to those new to the space.
  • We need better on-ramps to help people new to the space wrap their arms around the plethora specs and what they’re useful for.
  • Well-written profiles are a way of managing the complexity. For instance, FAPI 2 limits choices, increasing both interoperability and security.
  • The amount of innovation happening is a sign of success!

Thanks to the organizers for a great tenth OAuth Security Workshop! And special thanks to the colleagues from Signicat who did a superb job with local arrangements in Reykjavík!

Proposed Candidate Recommendation for Controlled Identifiers

By

On February 4, 2025

In Cryptography, JSON, Specifications, W3C

W3C logoThe W3C Verifiable Credentials Working Group has published a Snapshot Candidate Recommendation of the Controlled Identifiers specification. This follows the five Candidate Recommendation Snapshots published by the working group in December 2024. Two of these specifications, including Securing Verifiable Credentials using JOSE and COSE, depend upon the Controlled Identifiers spec. The planned update to the W3C DID specification also plans to take a dependency upon it.

A W3C Candidate Recommendation Snapshot is intended to become a W3C Candidate Recommendation after required review and approval steps.

Thanks to my co-editor Manu Sporny and working group chair Brent Zundel for their work enabling us to reach this point.

Twenty Years of Digital Identity!

By

On February 2, 2025

In Events, IETF, JSON, OAuth, OpenID, People

Kim Cameron first told me what Digital Identity is on February 1, 2005. He said that the Internet was created without an identity layer. He encouraged me “You should come help build it with me.” I’ve been at it ever since!

What I wrote about digital identity a decade ago remains as true today:

An interesting thing about digital identity is that, by definition, it’s not a problem that any one company can solve, no matter how great their technology is. For digital identity to be “solved”, the solution has to be broadly adopted, or else people will continue having different experiences at different sites and applications. Solving digital identity requires ubiquitously adopted identity standards. Part of the fun and the challenge is making that happen.

I’m not going to even try to list all the meaningful identity and security initiatives that I’ve had the privilege to work on with many of you. But I can’t resist saying that, in my view, OpenID Connect, JSON Web Token (JWT), and OAuth 2.0 are the ones that we knocked out of the park. I tried to distill the lessons learned from many of the initiatives, both successes and failures, during my 2023 EIC keynote Touchstones Along My Identity Journey. And there’s a fairly complete list of the consequential things I’ve gotten to work on in my Standards CV.

I’ll also call attention to 2025 marking twenty years of the Internet Identity Workshop. I attended the first one, which was held in Berkeley, California in October 2005, and all but one since. What a cast of characters I met there, many of whom I continue working with to this day!

As a personal testament to the value of IIW, it’s where many of the foundational decisions about what became JWS, JWE, JWK, JWT, and OpenID Connect were made. Particularly, see my post documenting decisions made at IIW about JWS, including the header.payload.signature representation of the JWS Compact Serialization and the decision to secure the Header Parameters. And see the posts following it on JWE decisions, naming decisions, and JWK decisions. IIW continues playing the role of enabling foundational discussions for emerging identity technologies today!

It’s been a privilege working with all of you for these two decades, and I love what we’ve accomplished together! There’s plenty of consequential work under way and I’m really looking forward to what comes next.

Mike Jones Kim with Coffee

Images are courtesy of Doc Searls. Each photo links to the original.

Proposed Second Candidate Recommendation for Securing Verifiable Credentials using JOSE and COSE

By

On January 2, 2025

In CBOR, Claims, Cryptography, JSON, Specifications, W3C

W3C logoThe W3C Verifiable Credentials Working Group published the Snapshot Second Candidate Recommendation of the Securing Verifiable Credentials using JOSE and COSE specification just before the holidays. This was one of five Candidate Recommendation Snapshots published by the working group at the same time, including for the Verifiable Credentials Data Model 2.0, which I’m also an editor of. A W3C Candidate Recommendation Snapshot is intended to become a W3C Candidate Recommendation after required review and approval steps.

As I wrote about the First Candidate Recommendation, VC-JOSE-COSE secures VC Data Model payloads with JOSE, SD-JWT, or COSE signatures. And while I’m admittedly not a fan of JSON-LD, to the extent that Verifiable Credentials using the JSON-LD-based VC Data Model are in use, I’m committed to there being a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to sign these credentials.

One significant change since the First Candidate Recommendation was splitting the Controller Document text out into its own specification called Controlled Identifier Document 1.0. Publishing a Candidate Recommendation Snapshot for it is planned for next week. Part of why it became its own specification is so that it can be referenced by the planned update to the W3C DID specification.

Thanks to my co-editor Gabe Cohen and working group chair Brent Zundel for the significant work they both put in to help us reach this point!

Integrity Properties for Federations

By

On December 6, 2024

In Federation, OpenID, People, Specifications

OpenID logoI’m writing to highly recommend the article “How to link an application protocol to an OpenID Federation 1.0 trust layer” by Vladimir Dzhuvinov. In it, he defines two kinds of integrity for Federations, and describes how to achieve them:

  • Federation Integrity, which is defined as:

    • This ensures mutual trust between two entities is established always from a common trust anchor. Any resolved metadata and policies that govern the client application and the OpenID provider in a transaction will then fall under the rules of the same federation and thus will be aligned and consistent with one another.

  • Metadata Integrity, which is defined as:

    • It ensures the trust chains for an entity to a given trust anchor will invariably result in consistent metadata and policies. The natural way to achieve this is for the federation topology under a trust anchor to form a tree. Topologies that lead to multiple paths from a leaf entity to a trust anchor are to be avoided.

The article also explores how application protocols, such as OpenID Connect or digital wallet protocols, can achieve those properties in practice (and when they do and don’t need to).

Finally, I’ll note that, as a result of Vladimir’s and others’ thinking about the topic, we just added a section on Federation Topologies to the OpenID Federation specification, which provides concrete guidance on how to achieve Metadata Integrity.

I’ll stop here so as not to repeat all the useful content in Vladimir’s article. By all means, give it read!

Three New Specs Enhancing OpenID Federation and New Contributors

By

On November 30, 2024

In Federation, OpenID, People, Specifications

OpenID logoThe OpenID Connect working group recently adopted three new specifications that build upon and provide new capabilities to OpenID Federation. But I’m not only happy about these because of the engineering benefits they bring.

I’m particularly happy because they bring new active contributors to the work, specifically Michael Fraser and Łukasz Jaromin, as well as continuing the strong work by Giuseppe De Marco, who’s become a leader in the space. They’re also supported by a few veterans: Roland Hedberg, John Bradley, and yours truly, plus now the full OpenID Connect working group.

Here’s the three new specifications, along with an abstract for each of them:

1. OpenID Federation Extended Subordinate Listing

This specification acts as an extension to OpenID Federation 1.0. It outlines methods to interact with a given Federation with a potentially large number of registered Entities, as well as mechanisms to retrieve multiple entity statements along with associated details in a single request.

2. OpenID Federation Wallet Architectures

As digital wallets become increasingly deployed for managing identity credentials, establishing an architecture for trusted communication is required to allow each participant in the ecosystem to evaluate other participants’ compliance with mutual trust frameworks and accomplish secure and trusted transactions.

This specification defines how to use OpenID Federation 1.0 to enhance the security and interoperability of wallet ecosystems, facilitating trust establishment among the parties and enabling secure metadata exchange and policy application across large scale deployments. It outlines the general architecture of a federated trust infrastructure for wallet ecosystems, identifying participant roles and describing the use of those roles.

3. OpenID Connect Relying Party Metadata Choices

This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This functionality is particularly useful when Automatic Registration, as defined in OpenID Federation 1.0, is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.

Thanks to the members of the OpenID Connect working group who helped refine them before adoption, and are now working on progressing them in the working group.

OpenID Presentations at October 2024 OpenID Workshop and IIW plus New Specifications

By

On October 29, 2024

In Events, OpenID, Specifications

OpenID logoI gave the following presentation on work in the OpenID Connect working group at the Monday, October 28, 2024 OpenID Workshop at Microsoft:

I also gave this invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, October 29, 2024:

There’s more happening in the OpenID Connect working group than at any other time since we started the OpenID Connect work. In fact, two new specifications were adopted today!

Thanks to all who helped us get there!

Page 1 of 34

Next

Powered by WordPress & Theme by Anders Norén