Mike Jones: self-issued

Musings on Digital Identity

Integrity Properties for Federations

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

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

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!

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!

OpenID Connect specifications published as ISO standards

OpenID logoI’m thrilled to report that the OpenID Connect specifications have now been published as ISO/IEC standards. They are:

I submitted the OpenID Connect specifications for publication by ISO as Publicly Available Specifications (PAS) for the OpenID Foundation in December 2023. Following the ISO approval vote, they are now published. This should foster even broader adoption of OpenID Connect by enabling deployments in jurisdictions around the world that have legal requirements to use specifications from standards bodies recognized by international treaties, of which ISO is one.

Before submitting the specifications, the OpenID Connect working group diligently worked through the process of applying errata corrections to the specifications, so that the ISO versions would have all known corrections incorporated.

Having successfully gone through the ISO PAS submission process once, the OpenID Foundation now plans to submit additional families of final specifications for publication by ISO. These include the FAPI 1.0 specifications, and once they’re final, the eKYC-IDA specifications and FAPI 2.0 specifications.

Thanks to all who helped us achieve this significant accomplishment!

ISO/IEC 26131:2024 Cover Page

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:

Fully-Specified Algorithms Specification Addressing Feedback from IETF 120

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to incorporate feedback from IETF 120 in Vancouver. Specifically, the registrations for fully-specified Elliptic Curve Diffie-Hellman (ECDH) algorithms in draft 03 were removed, along with the previously proposed fully-specified ECDH algorithm identifiers, while continuing to describe how to create fully-specified ECDH algorithms in the future, if needed.

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!

Fully-Specified Algorithms Specification Addressing Working Group Last Call Comments

IETF logoOrie Steele and I have updated the “Fully-Specified Algorithms for JOSE and COSE” specification to incorporate working group last call (WGLC) feedback. Thanks to all who took the time to comment on the draft. Your feedback was exceptionally actionable and helped to substantially improve the specification. Responses to each WGLC comment thread were sent on the IETF JOSE working group mailing list.

The updated draft attempts to discuss the full range of the problems created by polymorphic algorithm identifiers. Guided by working group feedback, it strikes an engineering balance between which of these problems to fix immediately in the specification and which to describe how future specifications can fix later as the need arises.

I look forward to discussing next steps for the specification at IETF 120 in Vancouver.

The specification is available at:

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:

CBOR Web Token (CWT) Claims in COSE Headers is now RFC 9597

IETF logo The CBOR Web Token (CWT) Claims in COSE Headers specification has been published as RFC 9597! This closes a gap for COSE relative to JOSE, adding the ability to use CWT claims in COSE header parameters, just as JWT claims can be used in JOSE header parameters.

The specification abstract is:

This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all.

Special thanks to my co-author Tobias Looker, who had a use case for this functionality and wrote an RFC with me defining it (his first!). It was a pleasure working with Tobias on the draft as we navigated the ins and outs of working group feedback and IETF processes. The spec was refined by the journey we took together. And as with CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter (now RFC 9596) that immediately preceded it, I believe the CBOR and COSE ecosystems are better for it.

COSE “typ” (type) Header Parameter is now RFC 9596

IETF logo The CBOR Object Signing and Encryption (COSE) “typ” (type) Header Parameter specification has been published as RFC 9596! This closes a gap for COSE relative to JOSE, adding the ability to use media types to declare the content of the complete COSE object.

The specification abstract is:

This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) “typ” (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, “JSON Web Token Best Current Practices”) to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter.

Special thanks to my co-author Orie Steele, who pointed out the gap and proposed that we close it. He was an active participant and insightful partner in making this RFC happen (his first!). The CBOR and COSE ecosystems are better for it.

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)!

Proposed Implementer’s Draft of OpenID Federation

OpenID logoThe OpenID Connect working group has started working group last call (WGLC) for a proposed Implementer’s Draft of the OpenID Federation specification. As described in the WGLC message:

OpenID Federation -35 has been published at https://openid.net/specs/openid-federation-1_0-35.html and https://openid.net/specs/openid-federation-1_0.html. This draft is being proposed as the fourth (and hopefully final) Implementer’s Draft of the specification.

An Implementer’s Draft is a stable version of a specification providing intellectual property protections to implementers of the specification. The two-week working group last call ends on Friday, May 31, 2024. Unless reasons are identified during the last call to substantially revise the specification, the 45-day OpenID Foundation-wide review of the specification for approval as an OpenID Implementer’s Draft will shortly follow.

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

Securing Verifiable Credentials using JOSE and COSE is now a W3C Candidate Recommendation

W3C logoThe Securing Verifiable Credentials using JOSE and COSE specification (a.k.a. VC-JOSE-COSE) has reached W3C Candidate Recommendation status. The Candidate Recommendation milestone is described in the W3C Process document. Please review the Candidate Recommendation of VC-JOSE-COSE. Thanks especially to Gabe Cohen, Orie Steele, and Brent Zundel for doing the hard work of getting us to this point!

Since I last wrote about this work, the W3C Verifiable Credentials Data Model (VCDM), which is also at Candidate Recommendation stage, has been narrowed to only use JSON-LD to represent credentials. VC-JOSE-COSE secures VCDM payloads with JOSE, SD-JWT, or COSE signatures. While I’m admittedly not a fan of JSON-LD, to the extent that Verifiable Credentials using the VCDM are in use, I’m committed to finishing a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to sign these credentials.

Of course, there are lots of Verifiable Credential formats to choose from, and more on the way. Choices already existing include ISO mDoc, IETF SD-JWT, IETF JSON Web Proof (JWP), and W3C VCDM. The IETF is also planning to create a CBOR-based selective disclosure representation in the newly formed SPICE working group. It will be interesting to see how these all shake out in the marketplace!

OpenID Federation Session at April 2024 IIW

OpenID logoJohn Bradley and I convened a session on Trust Establishment with OpenID Federation at the Internet Identity Workshop (IIW) on Thursday, April 18, 2024. The material used to drive the discussion was:

The session was well attended and the discussion lively. Numerous people with trust establishment problems to solve contributed, including experts from the SAML federation world, people involved in digital wallet projects, and several people already using or considering using OpenID Federation. Thanks to all who participated!

OpenID Presentations at April 2024 OpenID Workshop and IIW

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

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

Fully-Specified Algorithms Presentation at 2024 OAuth Security Workshop

OAuth Security WorkshopI gave a presentation on Fully-Specified Algorithms for JOSE and COSE at the 2024 OAuth Security Workshop in Rome. The slides used to update participants on the progress of the work are available as PowerPoint and PDF.

Thanks to the organizers for another great OAuth Security Workshop! And special thanks to the colleagues from Fondazione Bruno Kessler who did a great job with local arrangements in Rome!

Page 1 of 33

Powered by WordPress & Theme by Anders Norén