Mike Jones: self-issued

Musings on Digital Identity

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

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

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

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

COSE “typ” (type) Header Parameter Specification Addressing Feedback from IETF 117

IETF logoOrie Steele and I have updated the COSE “typ” (type) Header Parameter Specification to address feedback received during IETF 117 in San Francisco. Specifically, the spec now requires that the typ header parameter only be used in the protected header parameters. And we described the implications of the unprotected header parameters changing.

The specification is available at:

We believe that having done this, the spec is now ready for working group adoption.

Yes, I’m an independent consultant now

Michael B. JonesAs many of you know, three months ago I decided to hang out my own shingle and become an independent consultant. I couldn’t be happier! I have a great initial set of clients I’m working with to create things they and I believe in and I have room for a few more.

For all the changes in my life, some things have remained constant: I’m still motivated by Kim Cameron‘s quest to build the Internet’s missing identity layer. I’m still mentoring smart new contributors to the identity space. I’m still contributing to specifications that will get used and make a difference. I’m still thinking about the big picture – especially everything it will take to grow interoperable ecosystems that enable everyday people to get useful things done. I’m still collaborating with fantastic people!

I named my business Self-Issued Consulting. Special thanks to Heather Flanagan, who clearly explained to me why I want to be a consultant at this juncture in my career, and who told me to write a Standards CV before I launched my professional Web site.

Yes, I’m grateful for the 30½ years I had at Microsoft. My career wouldn’t be remotely the same without them. But at the same time, soon after 30 years, I realized that it was time for a change. I’m grateful for all my friends who have helped me chart this next course on my identity journey. You know who you are!

I can’t resist but end with a few musical phrases that have been running through my head during this transition:

  • All things must pass – George Harrison
  • After changes upon changes / We are more or less the same – Simon and Garfunkel
  • Getting so much better all the time – The Beatles

COSE “typ” (type) Header Parameter Specification

IETF logoOrie Steele and I have created a specification to add a typ header parameter to COSE – something increasingly widely used in JOSE but currently missing in COSE. The introduction to the spec tells the story:

CBOR Object Signing and Encryption (COSE) [RFC9052] defines header parameters that parallel many of those defined by the JSON Object Signing and Encryption (JOSE) [RFC7515] [RFC7516] specifications. However, one way in which COSE does not provide equivalent functionality to JOSE is that it does not define an equivalent of the typ (type) header parameter, which is used for declaring the type of the entire JOSE data structure. The security benefits of having typ (type) are described in the JSON Web Token Best Current Practices [RFC8725], which recommends its use for “explicit typing” — using typ values to distinguish between different kinds of objects.

This specification adds the equivalent of the JOSE typ (type) header parameter to COSE so that the benefits of explicit typing can 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, allowing both integer CoAP Content-Formats [IANA.CoAP.ContentFormats] values and string Media Type [IANA.MediaTypes] values to be used.

The specification is available at:

We plan to socialize this specification at IETF 117 in San Francisco later this month.

OAuth 2.0 Protected Resource Metadata now with WWW-Authenticate

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

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

The specification is available at:

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

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

  • Added Acknowledgements section.
  • Addressed WGLC feedback. Specifically…
  • Added statement about being able to use the header parameter in any COSE object.
  • Moved statement about verifying that claim values present in both the header and payload are identical from the Security Considerations to the body of the specification.

The specification is available at:

Lifetime Achievement Award at EIC 2023

EIC 2023 LogoI was surprised and deeply honored to receive a Lifetime Achievement Award from Kuppinger Cole at EIC 2023. As I recalled when accepting the award, when Kim Cameron received the same award about a decade ago, he said from the podium “No, don’t do this! My career isn’t over! I’m not done contributing!” Kim always had a wicked wit. ;-)

Coincidentally, I described some of the achievements that led to the award during my keynote Touchstones Along My Identity Journey. After a couple of times of me saying “We won an award for that” during the keynote, I was amused that the audience would break out into laughter each subsequent time that I mentioned another award. Like this award, the audience’s reaction was unexpected and delightful.

EIC 2023 Lifetime Award

Smiling with EIC 2023 Lifetime Award

EIC 2023 Lifetime Award with Martin Kuppinger

EIC 2023 Awards with Rachelle Sellung

Touchstones Along My Identity Journey

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

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

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

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

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

EIC 2023 Keynote Photo

EIC 2023 Keynote Photo with Kim Cameron

EIC 2023 Keynote Photo for OAuth

Current Work and Future Trends in Selective Disclosure

EIC 2023 LogoThe session Current Work and Future Trends in Selective Disclosure at EIC 2023 covered a lot of foundational work happening in the space of Selective Disclosure right now. Selective Disclosure enables you to have a token with many claims (say, an ISO Mobile Drivers’ License (mDL)), and only release the claims necessary for the interaction — for instance, your birthdate but not your home address. Selective Disclosure enables Minimal Disclosure. This is sometimes realized using Zero Knowledge Proofs (ZKPs) but that’s not always necessary.

The agenda for the session was:

Our presentations are available in (PowerPoint) and PDF.

EIC 2023 Disclosure Issuer Holder Verifier Model

How do you know who to trust?

EIC 2023 LogoGiuseppe De Marco and I presented the session How do you know who to trust? at EIC 2023.

A key question when granting access to resources is ‘Who do you trust?’. It’s often important to know who the party is that you’re interacting with and whether they’ve agreed to the terms and conditions that apply when accessing a resource.

OpenID Connect enables identities of participants to be securely established but doesn’t answer the question of whether a participant is trusted to access a resource such as your personal data. A complementary mechanism is needed to do that. In small-scale and static deployments, it’s possible to keep a list of the trusted participants. However, in large-scale and dynamic deployments, that doesn’t scale.

This presentation described how the OpenID Connect Federation protocol enables scalable trust establishment with dynamic policies. It does so by employing trust hierarchies of authorities, each of which are independently administered. Examples of authorities are federation operators, organizations, departments within organizations, and individual sites.

Two OpenID Connect Federations are deployed in Italy, enabling secure access to digital services operated by Italian public and private services with Italian digital identities. This presentation described why OpenID Connect Federation was selected for them and how it meets their needs. OpenID Connect Federation is also being used by the GAIN PoC.

Our presentation is available in (PowerPoint) and PDF.

EIC 2023 Federation Photo

Initial Reanimiated JOSE Working Group Specifications Published

IETF logoFollowing a call for adoption by the restarted JSON Object Signing and Encryption (JOSE) Working Group, I’m pleased to report that the three initial working group specifications have been published. They are:

JSON Web Proof, with abstract:

This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a JSON Web Proof (JWP). Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms.

JSON Proof Algorithms, with abstract:

The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

JSON Proof Token, with abstract:

JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs).

Thanks to Jeremie Miller and David Waite for helping us get there!

OAuth DPoP specification is in the hands of the RFC Editor

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

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

The latest version of the specification is available at:

Implement and deploy early and often!

First Public Working Draft of Securing Verifiable Credentials using JSON Web Tokens

W3C logoThe First Public Working Draft (FPWD) of the Securing Verifiable Credentials using JSON Web Tokens (VC-JWT) specification has been published. The FPWD milestone is described in the W3C Process document. This draft is another step on the way to a Native JWT Representation for Verifiable Credentials.

Please review the First Public Working Draft of VC-JWT. Thanks especially to Orie Steele for making this happen!

OpenID Presentations at April 2023 OpenID Workshop and IIW

OpenID logoI gave the following presentation at the Monday, April 17, 2023 OpenID Workshop at Microsoft:

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

OAuth DPoP Nearing Completion

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

Recent changes as described in the history log are:

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

The specification is available at:

Native JWT Representation for Verifiable Credentials

W3C logoFor the first time, there is now a native JSON Web Token (JWT) representation for Verifiable Credentials. This representation uses IANA-registered JWT claims whenever applicable. Among other improvements and simplifications, this means that we finally have a Verifiable Credentials representation that doesn’t require the use of JSON-LD.

The native JWT representation explicitly isn’t a mapping from the VC Data Model. This mapping in the VC 1.1 specification resulted in ambiguities about whether to duplicate VC Data Model claims in the VC-JWT representation (the “in addition to” option) or whether to delete them from the VC Data Model representation (the “instead of” option). These ambiguities harmed interoperability. Rather, the 2.0 VC-JWT representation is its own simpler native JWT data structure.

See the new native JWT VC representation in the Version 2 section of the “Securing Verifiable Credentials using JSON Web Tokens” specification. You can also compare it there to the Version 1.1 representation, which is a mapping from the VC Data Model with the “in addition to” and “instead of” choices.

This accomplishment is the product of the vision, passion, and perseverance of many advocates of simplifying Verifiable Credentials. Foremost among them is Orie Steele – my co-editor for the VC-JWT specification. I’ll also observe that the pull request creating this functionality had an unprecedented fifteen approvers – an indication of the broad support for this direction for Verifiable Credentials. I am proud to have played a role in making it happen.

JSON Object Signing and Encryption (JOSE) Working Group Reanimated

IETF logoI’m thrilled that the IETF has restarted the JSON Object Signing and Encryption (JOSE) Working Group. It’s chartered to work on JSON- and CBOR-based representations for Zero-Knowledge Proofs (ZKPs), selective disclosure enabling minimal disclosure, and non-correlatable presentation. The representations are planned to use the three-party model of Issuer, Holder, and Verifier utilized by Verifiable Credentials.

See the newly approved JOSE charter at https://datatracker.ietf.org/doc/charter-ietf-jose/03/. The working group will be chaired by Karen O’Donoghue, John Bradley, and John Mattsson, with the assigned area director being Roman Danyliw.

I believe this is a great outcome because the JOSE working group participants already have expertise creating simple, widely-adopted JSON-based cryptographic formats, such as JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK). The new formats will be peers to JWS, JWE, and COSE, reusing elements that make sense, while enabling use of new cryptographic algorithms whose inputs and outputs are not representable in the existing JOSE and COSE formats.

If you’re interested in the work, please join the JOSE mailing list at https://www.ietf.org/mailman/listinfo/jose if you’re not already a member. Also, plan to participate in IETF 116 Yokohama, where we should be able to have the first meeting of the reconstituted working group. I hope to see you there!

As background, the first step in the JOSE rechartering was the JSON Web Proofs (JWP) BoF at IETF 114 in Philadelphia sponsored by Security Area Director Roman Danyliw and chaired by Karen O’Donoghue and John Bradley, during which Jeremie Miller, Kristina Yasuda, Tobias Looker, and I presented. That was follwed by a Virtual Interim JWP BoF in October, 2022, review on the ietf-announce mailing list, and multiple IESG discussions.

All of which brings us back to the (now recurring!) question: “What Would JOSE Do?” Join us and be part of answering it!

What Would Jose Do?

OAuth DPoP Specification Addressing Area Director Review Comments

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

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

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

The specification is available at:

OpenID Presentations at November 2022 OpenID Workshop and IIW

OpenID logoI gave the following presentation at the Monday, November 14, 2022 OpenID Workshop at VISA:

I also gave the following invited “101” session presentation at the Internet Identity Workshop (IIW) on Tuesday, November 15, 2022:

The OpenID Connect Logout specifications are now Final Specifications

OpenID logoThanks to all who helped us reach this important milestone! This was originally announced on the OpenID blog. These now Final specifications are:

Don’t just sign in. Also sign out!

Page 3 of 33

Powered by WordPress & Theme by Anders Norén