Musings on Digital Identity

Category: Claims Page 1 of 13

Major updates to JSON Web Proof specifications in preparation for IETF 123

IETF logoDavid Waite and I made significant updates to the JSON Web Proof, JSON Proof Algorithms, and JSON Proof Token and CBOR Proof Token specifications in preparation for presentation and discussions in the JOSE working group at IETF 123 in Madrid. The most significant updates were:

  • Changed the Single Use algorithm representations to use a common presentation proof format for both the Compact and CBOR serializations.
  • Defined a new binary “Presentation Internal Representation” so that the holder signature protects the entire presentation.
  • Changed the MAC algorithm to directly sign the binary Combined MAC Representation rather than convert it to a JWS.
  • Added step-by-step instructions for verification of a presentation.
  • Added CBOR examples.
  • Use JSON Proof Token and CBOR Proof Token terminology.
  • Aligned media type names and added media type suffixes.
  • Removed the JSON Serialization (leaving the Compact Serialization and the CBOR Serialization).
  • Made terminology changes to make the meanings of terms more intuitive.

These changes went into the -09 and -10 drafts of the specifications. See more details in the History entries of each spec.

The current drafts are available at:

Thanks to David Waite for doing the heavy lifting to make the bulk of these architectural changes, and especially for writing the code that makes the examples real!

More SPICEyness

IETF logoIn April, I wrote about several useful developments in the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. I’ve recently contributed to progressing several specifications in preparation for the SPICE working group meeting at IETF 123 in Madrid. Here’s a tour…

I’ve become a contributor to the Selective Disclosure CWT (SD-CWT) specification. The draft we just published in preparation for IETF 123 contains significant enhancements, including better alignment with both SD-JWT and CWT, clearer and simpler specification of the use of encryption, creation of the Verifiable Credential Type Identifiers registry, using a CBOR simple value for redacted claims, and numerous editorial improvements. See the history entry for more details. This was joint work with Rohan Mahy and Orie Steele.

I’ve become an editor of the OpenID Connect Standard Claims Registration for CBOR Web Tokens specification, along with Beltram Maldant. It creates CWT equivalents of the standard JWT claims defined by OpenID Connect. The draft we just published in preparation for IETF 123 aligns the terminology used with OpenID Connect. I believe it’s ready for working group last call.

Brent Zundel and I updated the GLobal Unique Enterprise (GLUE) Identifiers specification to fix some links and update his association to Tradeverifyd. I believe this one is also ready for working group last call.

Finally, Brent and I updated the Traceability Claims specification to tighten up many of the claim definitions. See the history entries for details.

I’m looking forward to continued progress at the SPICE meeting in two weeks!

Ten Years of JSON Web Token (JWT) and Preparing for the Future

IETF logoTen years ago this week, in May 2015, the JSON Web Token (JWT) became RFC 7519. This was the culmination of a 4.5 year journey to create a simple JSON-based security token format and underlying JSON-based cryptographic standards. The full set of RFCs published together was:

  • RFC 7515: JSON Web Signature (JWS)
  • RFC 7516: JSON Web Encryption (JWE)
  • RFC 7517: JSON Web Key (JWK)
  • RFC 7518: JSON Web Algorithms (JWA)
  • RFC 7519: JSON Web Token (JWT)
  • RFC 7520: Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)
  • RFC 7521: Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7522: Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants
  • RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

It’s certainly the case that we co-designed JWT and its underpinnings with OpenID Connect, while also attempting to create general-purpose, widely useful standards. Given the adoption that’s ensued, it seems that we succeeded.

As I wrote in my post JWTs helping combat fraudulent and unwanted telephone calls, “It’s often said that one sign of a standard having succeeded is that it’s used for things that the inventors never imagined.” I’m gratified that this applies to JWT and the related specifications. As was written in the post Essential Moments in the OAuth and OpenID Connect Timeline, it’s now hard to imagine an online security world without these standards.

That said, there’s work underway to keep JWTs and the use of them secure for the next decade. Five years ago, the JSON Web Token Best Current Practices specification was created. As I wrote then:

This Best Current Practices specification contains a compendium of lessons learned from real JWT deployments and implementations over that period. It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise.

My coauthors Yaron Sheffer and Dick Hardt and I are now updating the JWT BCP to describe additional threats and mitigations that have become known in the last five years. See the updated JSON Web Token Best Current Practices specification.

Similarly, my coauthors Brian Campbell and Chuck Mortimore of the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants are updating it and related specifications to address vulnerabilities caused by ambiguities in the audience values of tokens sent to the authorization server. See the RFC7523bis specification.

I’m truly grateful that my coauthors John Bradley and Nat Sakimura and I created something useful and widely used ten years ago, of course with substantial contributions from the OAuth, JOSE, and OpenID Connect working groups. I look forward to what the next decade will bring!

Essential Moments in the OAuth and OpenID Timeline

OpenID logoOAuth logoDuende Software just posted an insightful piece titled Essential Moments in the OAuth and OpenID Connect Timeline. It’s a trip down memory lane, recounting significant developments in the identity and security standards repertoire that we now take for granted.

It reminds us that all of this has come about in the last 15 years. These standards didn’t happen by accident. They were all created to meet specific needs that we understood at the time. Fortunately, they’ve also largely stood the test of time. I’m proud to have been involved in creating many of them – of course, always in close collaboration with others.

W3C Verifiable Credentials 2.0 Specifications are Now Standards

W3C logoAs announced by the W3C, the Verifiable Credentials 2.0 family of specifications is now a W3C Recommendation. The new W3C Recommendations that I was an editor for are:

I joined the VC 2.0 journey in 2022 with the goal of there being a simple, secure, standards-based way to sign W3C Verifiable Credentials. The VC-JOSE-COSE specification accomplishes that – defining how to secure VC Data Model payloads with JOSE, SD-JWT, or COSE signatures. As I wrote when the Proposed Recommendations were published, 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 was committed to there being a solid VC-JOSE-COSE specification so there is a simple, secure, standards-based way to secure these credentials. That goal is now accomplished.

Particular thanks go to my co-editors of VC-JOSE-COSE Gabe Cohen and Mike Prorock, former editor Orie Steele, and working group chair Brent Zundel for the significant work they all both put in throughout the journey. And of course, Manu Sporny and Ivan Herman were always diligent about moving things along.

One of my personal mottos is “Finishing things matters”. This is now finished. As the song says, “What a long, strange trip it’s been”!

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

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

SPICEy Developments

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!

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

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!

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!

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

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!

COSE “typ” (type) Header Parameter Specification in RFC Editor Queue

IETF logoI’m pleased to report that the COSE “typ” (type) Header Parameter 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 CBOR Web Token (CWT) Claims in COSE Headers in the RFC Editor queue. Because of the reference to this spec by CWT Claims in Headers, they form a cluster, and therefore will become RFCs at the same time.

Eight Specifications Published in Preparation for IETF 119

IETF logoMy co-authors and I published updated versions of eight specifications in preparation for IETF 119 in Brisbane. The specifications span three working groups: JOSE, COSE, and OAuth. The updated specifications and outcomes when discussed at IETF 119 are as follows.

1, 2, & 3: JSON Web Proof, JSON Proof Algorithms, and JSON Proof Token. Updates were:

  • Normatively defined header parameters used
  • Populated IANA Considerations sections
  • Allowed proof representations to contain multiple base64url-encoded parts
  • Specified representation of zero-length disclosed payloads
  • Added Terminology sections
  • Updated to use draft-irtf-cfrg-bbs-signatures-05
  • Updated to use draft-ietf-cose-bls-key-representations-04
  • More and better examples
  • Improvements resulting from a full proofreading

Continued reviews and feedback from implementations are requested.

4: Fully-Specified Algorithms for JOSE and COSE. Updates were:

  • Published initial working group document following adoption
  • Added text on fully-specified computations using multiple algorithms
  • Added text on KEMs and encapsulated keys
  • Updated instructions to the designated experts

It was agreed during the JOSE meeting to describe what fully-specified algorithms for ECDH would look like, for consideration by the working group.

5: OAuth 2.0 Protected Resource Metadata. Updates 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 URL rather than resource identifier

It was decided to start working group last call during the OAuth meeting.

6: COSE “typ” (type) Header Parameter. Updates were:

  • Added language about media type parameters
  • Addressed working group last call comments
  • Changed requested assignment from 14 to 16 due to conflict with a new assignment
  • Addressed GENART, OPSDIR, and SECDIR review comments

This document is scheduled for the April 4, 2024 IESG telechat.

7: Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE. Updates were:

  • Changed to use key type EC for JOSE and equivalent EC2 for COSE for uncompressed key representations
  • Changed identifier spellings from “Bls” to “BLS”, since these letters are people’s initials

We received feedback to not add compressed key representations to the draft.

8: Use of Hybrid Public-Key Encryption (HPKE) with JavaScript Object Signing and Encryption (JOSE). Updates were:

It was decided to start a working group call for adoption during the JOSE meeting.

Thanks to all who contributed to the progress made on these specifications, both before and during IETF 119!

COSE “typ” (type) Header Parameter Specification Addressing IETF Last Call Feedback

IETF logoOrie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF Last Call. No normative changes were made.

Thanks to those that reviewed the specification!

The specification is available at:

Besides the spec being useful on its own, it’s worth noting that the CBOR Web Token (CWT) Claims in COSE Headers specification references this spec, and so won’t exit the RFC Editor queue as an RFC until this one also does.

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!

Page 1 of 13

Powered by WordPress & Theme by Anders Norén