“I’ve written recently about several IETF working groups that I think are worth watching. It seems only fair that I turn the same attention to one that I actually co-chair: the Secure Patterns for Internet CrEdentials (SPICE) Working Group.”

SPICE is working on one part of the much larger digital credentials problem: how existing and emerging IETF technologies can support credentials and presentations in interoperable ways. That includes credential formats, selective disclosure, architecture, and the various identifiers and claims that have to work together if any of this is going to be useful outside a single implementation.

If some of the terminology already sounds familiar, it should. Last year, I wrote about the difficulty of even agreeing on what to call digital credentials that can be verified. Different standards communities have developed overlapping models, formats, and terminology. SPICE does not solve all of that, but it is one place where the IETF is working out what its pieces of the puzzle should look like.

Now that the working group has been around long enough for documents to be moving through the standards process, it also offers a useful view into what happens when standards work goes well, when it very much does not, and how a working group figures out whether it still has a job to do.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Selective disclosure with SD-CWT

The largest piece of work so far is Selective Disclosure CBOR Web Tokens, or SD-CWT.

A CBOR Web Token, or CWT, is roughly the CBOR-based cousin of a JSON Web Token. CBOR, the Concise Binary Object Representation, provides a compact binary encoding that can be useful when message size, bandwidth, storage, or processing constraints matter. Super useful for IoT, workloads, etc.

An ordinary signed token, however, does not necessarily provide the privacy properties we want from a digital credential. If a credential contains your name, address, date of birth, and a professional qualification, a verifier interested in the qualification should not automatically need everything else.

SD-CWT adds selective disclosure to that model. The issuer can make claims selectively disclosable, and the holder can choose which of those claims to reveal when presenting the credential. A verifier can then validate the disclosed information without requiring all of the other claims to be exposed. The specification also supports key binding so that a presenter can demonstrate possession of the key associated with the credential.

There are important limits here. Selective disclosure is a data-minimization technique; it does not magically make every presentation unlinkable or prevent every form of correlation. The draft has an extensive privacy section covering those concerns, so do read that if you are at all interested in this topic.

SD-CWT has completed working group processing and has been submitted to the IESG. At IETF 127, we will also hear an interoperability report based on implementations of the specification.

That is an important stage. A specification can look perfectly reasonable on paper. Independent implementations trying to use it are considerably more informative.

Useful plumbing: OIDC claims in CWTs

Another document that has gone comparatively smoothly is OpenID Connect Standard Claims Registration for CBOR Web Tokens.

This one is much less ambitious, and I mean that as a compliment.

OpenID Connect (OIDC) defines a familiar collection of standard claims: things like name, given_name, family_name, email, and so on. Those claims are widely used with JSON Web Tokens. CWT has its own claims registry, but most of the OIDC claims were not registered there. The draft fixes that mismatch by registering their equivalents for CWT.

That may not sound exciting, but a surprising amount of useful standards work consists of this kind of plumbing. Two technologies already exist. People want to use them together. Rather than letting every implementation invent its own mapping, someone writes down the common answer and gets it registered.

OIDC-CWT has also been submitted to the IESG for publication.

So far, so good.

And then there’s GLUE

The experience with GLobal Unique Enterprise Identifiers, or GLUE, has been considerably messier. This one has definitely qualified as a Character-building Experience.

The underlying problem is reasonable. There are many existing identifier systems for organizations and other entities. GLUE attempts to establish a common convention for representing an issuer or subject using an identifier from one of those existing authorities. This is incredibly useful when you’re looking at things like supply chain records, especially when the entity that issued the original identifier no longer exists.

The draft went through working group review. It went through IETF Last Call. It went through directorate reviews. It was revised repeatedly. It reached IESG evaluation. It made it about 99 percent of the way through the process.

Then things went sideways.

The document attempted to establish its identifier scheme through URI registration; it also considered URN registration. Both approaches encountered objections during the required designated expert reviews. There was also a blocking IESG DISCUSS, including a question about whether the work fit appropriately within SPICE’s charter.

Those reviewers can do that. That is part of their role.

It does, however, raise a reasonable process question when objections of this fundamental nature appear after a document has already made it through working group consensus and most of the publication process. Authors and working groups put significant effort into getting a document that far. If there are lessons about when particular reviewers or expertise should be brought into the process, they are worth learning.

The discussion at IETF 126 showed that this was not simply a matter of fixing a few lines of text. Participants discussed the properties required of URNs and URIs, persistence, authority identifiers, registry design, and whether changes to the identifier scheme would require renewed working group consensus.

Since then, the chairs and our Area Director have agreed that GLUE needs to come back to the working group. The Datatracker still shows the document in “AD Followup,” but in practical terms, the next decision belongs to the group.

And the first question is not which syntax we prefer. It is whether there is enough interest to continue.

If there is, the working group needs to reconsider a fundamental design choice. Several possible directions have been suggested: a prefixed string, such as glue_<issuer>_<subject>, an HTTPS URL along the lines of https://<issuer>.example/entity/<subject>, or a URN such as urn:<issuer>:entity:<subject>.

Those are not three spellings of the same idea. They make different assumptions about namespaces, authority, persistence, registration, resolution, and how applications will actually use the identifier.

The current authors may also not have the cycles to take the document through another significant redesign. Another participant has offered to step in as an editor if the working group decides the problem is still worth solving.

So one of the questions for IETF 127 is quite basic: does GLUE still have a future, and if it does, what should it actually be?

That is a substantial reset for something that had looked almost finished.

Filling in the architecture

The other active piece of work is A Reference Architecture for Direct Presentation Credential Flows.

The working group adopted the document after IETF 126, and the current version is still quite early in its development. It defines roles and components involved when credentials are presented directly to a verifier, including the concept of a presentation mediator: the software responsible for managing and presenting credentials and making disclosure decisions.

I find that terminology particularly useful because “wallet” has become an overloaded term. It can mean an application, storage, an agent acting for a user, an entire credential-management system, or some combination of those things. Being more precise about the active component in a presentation flow helps.

The architecture also distinguishes the subject of a credential from the entity presenting it. That becomes increasingly important when credentials may be presented by an administrator, representative, organization, or software agent rather than by the credential subject personally.

There is still work to do. At IETF 126, participants specifically called for stronger security and privacy treatment and more attention to actual flow scenarios rather than simply describing the connections among named actors. The version adopted by the group has started filling out the model, but IETF 127 should tell us more about how much work remains.

IETF 127 is about more than four drafts

IETF 127 takes place November 14–20 in San Francisco. For SPICE, three discussions in particular should be informative: the interoperability experience with SD-CWT, what remains to be done on the architecture document, and whether GLUE has a viable path forward. But I think the meeting will tell us something else, too.

Working groups are not supposed to exist forever. They are chartered to solve particular problems. Eventually, one of two things should become clear: there is still substantive work that belongs in the group, or the group has largely accomplished what it was created to do.

SPICE may be getting closer to that decision point.

If the architecture work exposes substantial unanswered questions, if GLUE gets a new lease on life, or if interoperability testing identifies gaps that require more specification work, then there is clearly more for us to do.

If SD-CWT and OIDC-CWT continue toward publication, the architecture can be completed without opening up a large new body of work, and the working group decides not to restart GLUE, then SPICE may instead be approaching the point where it has done its job. That would be a successful outcome.

The discussions at IETF 127, therefore, cover several different stages of standards development at once. One specification is far enough along that implementations are testing interoperability. Another is relatively straightforward standards plumbing. An architecture is still being filled out and challenged. And a fourth document made it almost to publication before fundamental objections sent it back to the working group.

I don’t think the lesson from GLUE is simply that “the process worked.” There is a legitimate question about why the issues appeared so late and whether they could have been identified sooner. But a late review has to be capable of changing an outcome; otherwise, it is not much of a review.

Nor is the lesson that every document a working group adopts must eventually become an RFC. Consensus can change. Designs can encounter problems. The people doing the work can decide that another iteration is worth the effort, or that it isn’t.

That makes IETF 127 an interesting meeting for SPICE. It should give us a much better signal about whether the working group has another substantial phase of standards development ahead of it, or whether we are getting closer to being able to say: we did what we came here to do.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists.

If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.

Let’s get into it.

I’ve written recently about several IETF working groups that I think are worth watching. So, it only seems fair that I spend some time talking about the one I actually co-chair: Secure Patterns for Internet Credentials, better known as SPICE.

As usual, if you want links to the drafts, meeting notes, or background material I mention here, take a look at the written version of this post on my website. It includes all the links.

The SPICE Working Group has a fairly specific job: taking selected IETF building blocks and making them usable for digital credentials and presentations, while filling a small number of critical gaps where needed.

That includes work such as:

• Selective disclosure for CBOR Web Tokens.
• Common claims that can be used in digital credentials.
• An architecture for direct presentation flows.

If some of this vocabulary sounds familiar, it should. Last year, I wrote about the surprisingly difficult problem of agreeing on what to call digital credentials that can be verified. Different standards organizations are working on different parts of that space.

SPICE is not trying to define an overall digital credential system, nor is it the IETF’s main home for credential work. Its program of work is deliberately narrower: a handful of specifications and architectural work built largely on technologies that already exist elsewhere in the IETF.

Several documents in this working group have progressed well through the standards process. As a result, SPICE is an interesting example of not just how to move standards forward, but also what standards development looks like when things go well, when they get complicated, and when a working group starts asking whether it still has much work left to do.

So, let’s start with what has gone well, and then we’ll look at what went sideways.

---

Selective Disclosure for CBOR Web Tokens

The largest piece of work so far is Selective Disclosure for CBOR Web Tokens, usually shortened to SD-CWT.

A CBOR Web Token, or CWT, is roughly the CBOR-based cousin of a JSON Web Token. CBOR stands for Concise Binary Object Representation.

You don’t need to worry too much about the encoding details for this discussion. The useful thing to know is that CBOR provides a compact representation, which helps in environments where message size, bandwidth, storage, or processing constraints really matter.

However, an ordinary signed token creates some problems when you start using it as a digital credential.

Whether you’re talking about JSON or CBOR, the underlying issue is much the same. Imagine you have a credential containing information such as:

• Your name or an organization’s name.
• An address or the location where an organization was founded.
• A date of birth.
• Professional qualifications or IT certifications.

If someone needs to verify one piece of that information, they shouldn’t necessarily need to see everything else. They may not need to know who signed off on the credential, where that person is based, or what their employee number is.

SD-CWT adds selective disclosure to a CBOR Web Token. The issuer can make particular claims selectively disclosable. When the credential is presented later, the holder can choose which of those claims to reveal.

Consequently, a verifier can validate the disclosed information without requiring access to every other claim in the credential.

The specification also supports key binding, which allows a presenter to demonstrate possession of the key associated with the credential.

There are, however, limits to what this provides. Selective disclosure helps with data minimization, but it does not magically make every transaction anonymous, unlinkable, or impossible to correlate.

The draft is fairly explicit about those limits, which is important. If you’re interested in this area, I encourage you to read that part of the specification.

Security and privacy mechanisms are much more useful when a specification explains where its guarantees stop.

SD-CWT has completed working group processing and moved to the IESG, the Internet Engineering Steering Group. At the time of recording, it was essentially in the queue for publication, and I expected that to happen, hopefully, within the year.

At IETF 127, coming up in mid-November in San Francisco, we’re also expecting a report on interoperability testing by people implementing selective disclosure for CBOR Web Tokens.

I’m particularly interested to see what comes out of that work. A specification can look beautifully coherent when everyone is discussing it on paper and in GitHub issues. However, independent implementations trying to communicate with one another tend to uncover a whole different category of truth and accuracy.

---

Registering OpenID Connect Claims for CBOR Web Tokens

The second draft that has progressed well through the standards process, and is also waiting for publication, is the OpenID Connect Claims Registration for CBOR Web Tokens, known as OIDC CWT.

This document is far less ambitious than SD-CWT, and I mean that positively.

OpenID Connect, as a profile of OAuth, already defines a set of familiar claims, including:

• Name.
• Given name.
• Family name.
• Email address.

These claims are widely used in JSON Web Tokens. CBOR Web Tokens have their own claims registry, but most of the familiar OpenID Connect claims were not registered there.

The draft addresses that gap by registering the corresponding claims used in JSON Web Tokens for CBOR Web Tokens.

That’s basically it.

I think this is a good reminder that useful standards work does not always mean inventing a new architecture. Sometimes, two existing technologies simply need to work together, and someone needs to document the obvious common answer so that every implementer doesn’t invent a different approach.

A lot of interoperability depends on this kind of very boring plumbing.

OIDC CWT has moved on to the IESG, so it is also well on its way to publication.

So far, so good.

---

GLUE and the Problem With Late Stage Review

Then there’s the draft we refer to as GLUE, which stands for Global Unique Enterprise Identifiers.

The underlying problem it has been trying to solve is reasonable. There are many existing identifier systems for organizations and other entities, including IRS Employer Identification Numbers and Dun & Bradstreet numbers.

GLUE tries to establish a common convention for representing an issuer or subject using an identifier from one of those existing authorities, placing it into a common format for use in a historical record.

The document went through working group review, IETF Last Call, directorate reviews, and repeated revisions. Eventually, it reached IESG evaluation.

In other words, it made it about 99% of the way through the process.

And then things went sideways.

The document tried to establish its identifier approach using URNs and URIs, but both approaches encountered objections during the Designated Expert review.

These experts may not know everything about the use case behind Global Unique Enterprise Identifiers. However, they know a great deal about Uniform Resource Identifiers, name systems, and the assumptions that underpin them.

The designated expert looked at the proposed approach and said no.

There was also a blocking DISCUSS position in the IESG. One of the area directors raised an objection, questioning whether the proposal was a good idea and whether it fit within the working group’s charter.

It’s important to remember that reviewers have a responsibility to raise blocking concerns when they believe something needs to be addressed. That responsibility applies regardless of how far a document has progressed through the process.

At the same time, this situation raises reasonable questions about the process when fundamental objections emerge so late. By that point, the authors and working group have already invested substantial effort in the document.

One of the retrospectives we’ll need to have is why those concerns weren’t captured earlier. Was it something we missed? Was it something the reviewers missed? Who knows?

The discussion at IETF 126 made it fairly clear that this wasn’t a matter of fixing a sentence or two. There was fundamental disagreement with how the draft proposed to solve the problem.

People were discussing several underlying design questions, including:

• The properties required of URNs and URIs.
• Persistent identifiers and authority identifiers.
• Registry design.
• Whether a changed identifier scheme would require renewed working group consensus.

Since then, the chairs and our Area Director have agreed that the document needs to return to the working group because the proposed changes would fundamentally alter what went through the original process.

Essentially, it would become a different document, if it becomes anything at all.

If you look at the Datatracker at the time of writing, it may still show Area Director follow-up. Procedurally, however, the next meaningful decision belongs back with the working group.

And the first question won’t be, “What syntax should we use?”

Instead, we need to ask whether there is enough interest to continue working on the problem.

Some of the people who needed this kind of registry may have solved the problem another way by now, simply because the process has taken so long. The authors may also be tired of working on a document that has become so difficult to move forward.

On the other hand, there may still be enough interest to pursue it.

That is a question we need to put to the working group. If the answer is yes, we’ll need to reconsider the fundamental design choices.

Possible options include a prefix, a string, or an HTTPS URL. We might return to URNs, although I doubt it.

These may look like superficially different ways of writing the same identifier, but they aren’t interchangeable. They carry different assumptions about namespaces, authority, persistent registration, resolution, and how applications are expected to use the identifier.

There is also a practical concern: the current authors may not have the time or energy to take this document through another round of work. It has already taken a very long time.

Fortunately, another participant has offered to step up as an editor if the working group decides the problem is still worth solving.

So, stay tuned. At IETF 127, we’ll be discussing an unusual question for a document that seemed almost complete: does GLUE still have a future? And if it does, what should that future look like?

---

The Reference Architecture for Direct Presentation Credential Flows

There is one remaining document in our queue that hasn’t progressed as far through the process. It was adopted as a working group item relatively recently: the Reference Architecture for Direct Presentation Credential Flows.

The goal is to define the roles and components involved when credentials are presented directly to a verifier.

One term I particularly like in this architecture is Presentation Mediator. This is the active software component responsible for managing and presenting credentials and making disclosure decisions.

I find that a much more useful term than simply calling everything a wallet.

What exactly is a wallet? It has become one of those words that can refer to an application, storage, an agent, a credential management system, or all of those things at once.

More precise terminology should help us communicate more clearly about how these systems actually work.

The architecture also distinguishes the subject of a credential from the entity processing it. That distinction becomes increasingly important when a credential is presented by an administrator, an organizational representative, or software acting on someone else’s behalf.

There is still work to do on this document, including strengthening its treatment of security and privacy and providing more complete descriptions of the flows involved.

IETF 127 should give us a much better idea of how much work remains.

---

What Comes Next for the SPICE Working Group?

That brings me to the part I find particularly interesting as a chair. We’re not just talking about four drafts. We’re also talking about the lifecycle of the working group itself.

IETF working groups aren’t supposed to exist forever, although some of them certainly feel that way.

They are chartered to solve a particular problem. Eventually, one of two things should become clear: either there is still substantive work that belongs in the group, or the group has largely accomplished what it was created to do.

SPICE may be approaching that decision point.

There are several developments that could demonstrate that more work remains:

• The architecture work may expose substantial unanswered questions.
• GLUE may receive a new lease on life.
• Interoperability testing may reveal gaps that require further specification work on SD-CWT.

If those things happen, there will clearly be more for us to do.

On the other hand, if SD-CWT and OIDC CWT continue toward publication, the architecture can be completed without opening up a large new body of work, and if the working group decides not to restart GLUE, SPICE may be getting quite close to having completed its job.

That could mean closing the working group.

And that would not be a failure.

Closing a working group because it has completed its work is a successful outcome. The point is to solve the problem the group was created to address, not to keep the group alive indefinitely.

So, the next stage depends on what we learn from the remaining work, how the working group responds to the questions surrounding GLUE, and whether implementation and interoperability efforts uncover additional gaps.

These are the kinds of questions that make standards development interesting. Progress isn’t always a straight line, and reaching the final stages of a specification doesn’t guarantee that the underlying design has been fully settled.

Sometimes, the most useful outcome is recognizing that a proposed solution needs to change. At other times, it means recognizing that the work is nearly finished.

---

Final Thoughts on SPICE

That’s where we are with SPICE.

I’m sure some of this may sound like, “Okay, fascinating. Interesting. But why?”

We’re solving some very specific problems, and this is going to be a fairly niche podcast episode. Still, if you’re interested in digital credentials, selective disclosure, interoperability, or how IETF standards move from drafts toward publication, I encourage you to look back at the written post or read through some of the drafts themselves.

You may find them fun.

Thanks for your time.

And that’s it for this week’s episode. If this helped make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn at @hlflanagan.

If you enjoyed the show, be sure to subscribe and leave a rating and review on Apple Podcasts or wherever you listen.

You can also find the full written post at sphericalcowconsulting.com.

Stay curious, stay engaged, and let’s get these conversations going.