Mike Jones: self-issued

Musings on Digital Identity

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

By

On October 14, 2023

In Events, Specifications

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

Key points made were:

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

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

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

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

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

Fodder for the next discussion…

OpenID Presentations at October 2023 OpenID Workshop and IIW

By

On October 10, 2023

In Events, OpenID

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

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

Public Drafts of Third W3C WebAuthn and FIDO2 CTAP Specifications

By

On October 10, 2023

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

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

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

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

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is now RFC 9449

By

On September 7, 2023

In IETF, OAuth, Specifications

OAuth logoThe OAuth 2.0 Demonstrating Proof of Possession (DPoP) specification has been published as RFC 9449! As Vittorio Bertocci wrote, “One of the specs with the highest potential for (positive) impact in recent years.” I couldn’t agree more!

The concise abstract says it all:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

As I described in my 2022 Identiverse presentation on DPoP it’s been a Long and Winding Road to get here. Efforts at providing practical proof of possession protection for tokens have included:

  • SAML 2.0 Holder-of-Key Assertion Profile – Not exactly OAuth
  • OAuth 1.0 used PoP – But message signing too complicated
  • OAuth 2.0 MAC draft – Used similarly complicated signing
  • OAuth 2.0 HTTP Signing draft – Abandoned due to complexity
  • TLS Token Binding – Some browsers declined to ship it
  • OAuth 2.0 Mutual TLS – Client certs notoriously difficult to use
  • OAuth 2.0 DPoP – Today’s RFC aimed at simply and practically solving this important problem

As they say, I think this one’s the one! Implement, deploy, and enjoy!

Adoption Time! And Lessons Learned…

By

On September 6, 2023

In CBOR, IETF, JSON, OAuth, Specifications

IETF logoI’ve had two different IETF specifications adopted by two different working groups in the last two days – a pleasant coincidence! Yesterday, the COSE “typ” (type) Header Parameter specification was adopted by the COSE working group. Today, the OAuth 2.0 Protected Resource Metadata specification was adopted by the OAuth working group. Their journeys from individual drafts to working group drafts couldn’t have been more different!

As I was musing with Phil Hunt, who wrote the original individual draft of OAuth 2.0 Protected Resource Metadata with me, I’m pretty sure that this is the longest time from writing an individual draft to it becoming a working group draft in my experience: August 3, 2016 to September 6, 2023 – seven years and a month!

Whereas, the time from the individual draft of COSE “typ” (type) Header Parameter to the first working group draft was only three months: July 8, 2023 to September 5, 2023. Which got me thinking… Is that the fastest progression I’ve had?

It turns out that my fastest time from individual draft to working group draft was for the JWK Thumbprint URI specification which I wrote with Kristina Yasuda. It went from individual draft to working group draft in only two months: November 24, 2021 to January 28, 2022. (And it became RFC 9278 on August 9, 2022 – less than nine months from start to finish, which I believe is also a personal record.)

Ironically, while OAuth 2.0 Protected Resource Metadata took over seven years from individual to working group drafts, a closely-related draft, OAuth 2.0 Discovery (which became RFC 8414) was previously my fastest from individual draft to working group draft: 2.5 months! (The journey to becoming an RFC took 2.5 years.)

The other relative speed demon was Proof-Of-Possession Semantics for JSON Web Tokens (JWTs): 3.5 months from individual draft to working group draft and two years from start to RFC 7800.

What are my takeaways from all these musings about starting things?

Multiformats Considered Harmful

By

On September 5, 2023

In IETF, Specifications

IETF logoWhile I usually reserve my time and energy for advancing good ideas, I’m making an exception to publicly state the reasons why I believe “multiformats” should not be considered for standardization by the IETF.

1. Multiformats institutionalize the failure to make a choice, which is the opposite of what good standards do. Good standards make choices about representations of data structures resulting in interoperability, since every conforming implementation uses the same representation. In contrast, multiformats enable different implementations to use a multiplicity of different representations for the same data, harming interoperability. https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03#appendix-D.1 defines 23 equivalent and non-interoperable representations for the same data!

2. The stated purpose of “multibase” is “Unfortunately, it’s not always clear what base encoding is used; that’s where this specification comes in. It answers the question: Given data ‘d’ encoded into text ‘s’, what base is it encoded with?”, which is wholly unnecessary. Successful standards DEFINE what encoding is used where. For instance, https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2 defines that “x” is base64url encoded. No guesswork or prefixing is necessary or useful.

3. Standardization of multiformats would result in unnecessary and unhelpful duplication of functionality – especially of key representations. The primary use of multiformats is for “publicKeyMultibase” – a representation of public keys that are byte arrays. For instance, the only use of multiformats by the W3C DID spec is for publicKeyMultibase. The IETF already has several perfectly good key representations, including X.509, JSON Web Key (JWK), and COSE_Key. There’s not a compelling case for another one.

4. publicKeyMultibase can only represent a subset of the key types used in practice. Representing many kinds of keys requires multiple values – for instance, RSA keys require both an exponent and a modulus. By comparison, the X.509, JWK, and COSE_Key formats are flexible enough to represent all kinds of keys. It makes little to no sense to standardize a key format that limits implementations to only certain kinds of keys.

5. The “multihash” specification relies on a non-standard representation of integers called “Dwarf”. Indeed, the referenced Dwarf document lists itself as being at http://dwarf.freestandards.org/ – a URL that no longer exists!

6. The “Multihash Identifier Registry” at https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html#mh-registry duplicates the functionality of the IANA “Named Information Hash Algorithm Registry” at https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg, in that both assign (different) numeric identifiers for hash functions. If multihash goes forward, it should use the existing registry.

7. It’s concerning that the draft charter states that “Changing current Multiformat header assignments in a way that breaks backward compatibility with production deployments” is out of scope. Normally IETF working groups are given free rein to make improvements during the standardization process.

8. Finally, as a member of the W3C DID and W3C Verifiable Credentials working groups, I will state that it is misleading for the draft charter to say that “The outputs from this Working Group are currently being used by … the W3C Verifiable Credentials Working Group, W3C Decentralized Identifiers Working Group…”. The documents produced by these working groups intentionally contain no normative references to multiformats or any data structures derived from them. Where they are referenced, it is explicitly stated that the references are non-normative.

Fully-Specified Algorithms for JOSE and COSE

By

On August 29, 2023

In CBOR, Cryptography, IETF, JSON, Specifications

IETF logoOrie Steele and I have written a new specification creating algorithm identifiers for JOSE and COSE that fully specify the cryptographic operations to be performed – something we’d promised to do during our presentation to the JOSE working group at IETF 117. The introduction to the specification (quoted below) describes why this matters.

The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms] and COSE [IANA.COSE.Algorithms] contain two kinds of algorithm identifiers:

  • Fully Specified: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc. Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE.
  • Polymorphic: Those requiring information beyond the algorithm identifier to determine the cryptographic operations to be performed. Such additional information could include the actual key value and a curve that it uses. Examples are EdDSA in both JOSE and COSE and ES256 in COSE.

This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414] uses negotiation parameters like these (from an example in the specification):

"token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"]

OpenID Connect Discovery [OpenID.Discovery] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn] and FIDO Client to Authenticator Protocol (CTAP) [FIDO2] negotiate using COSE alg numbers.

This does not work for polymorphic algorithms. For instance, with EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are supported! This causes real problems in practice.

WebAuthn contains this de-facto algorithm definition to work around this problem:

-8 (EdDSA), where crv is 6 (Ed25519)

This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve – making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice.

This specification creates fully-specified algorithm identifiers for all registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully-specified algorithm identifiers. It furthermore deprecates the practice of registering polymorphic algorithm identifiers.

The specification is available at:

The Key Is Not Enough! – OpenID Connect Federation at OSW 2023

By

On August 27, 2023

In Events, Federation, OAuth, OpenID, Specifications

OAuth Security WorkshopVladimir Dzhuvinov gave the innovative and informative presentation “The Key Is Not Enough!” on OpenID Connect Federation at the 2023 OAuth Security Workshop in London. This action thriller of a presentation covers history, goals, mechanisms, status, deployments, and possible futures of the work. The comparisons between X.509 certificates and Federation Trust Infrastructure are particularly enlightening!

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

By

On August 25, 2023

In Events, OAuth, Specifications

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

By

On August 4, 2023

In CBOR, IETF, Specifications

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

By

On July 11, 2023

In People

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

By

On July 8, 2023

In CBOR, IETF, Specifications

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

By

On July 7, 2023

In IETF, OAuth, Specifications

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

By

On June 29, 2023

In CBOR, Claims, IETF, Specifications

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

By

On May 23, 2023

In Events, History, People

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

By

On May 22, 2023

In Claims, Cryptography, Events, Federation, FIDO, History, IETF, Information Cards, Interoperability, JSON, OAuth, OpenID, People, Phishing Resistance, Specifications, Windows CardSpace

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

By

On May 22, 2023

In Claims, Cryptography, Events, People

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?

By

On May 22, 2023

In Events, Federation, OpenID, People

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

By

On May 8, 2023

In CBOR, Claims, Cryptography, IETF, JSON, Privacy, Specifications

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

By

On May 3, 2023

In IETF, OAuth, Specifications

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!

Page 3 of 33

Previous

Next

Powered by WordPress & Theme by Anders Norén