SPICE Meeting @ IETF 123

Tuesday 2025-07-22

Use cases

https://datatracker.ietf.org/doc/html/draft-ietf-spice-use-cases
Brent Zundel

In which we learn how pants are bad. Good thing that there aren't too
many people from the UK where that means something else entirely.
Slides describe talk track, work completed since last meeting and new
use cases
Digital wallets use case - do nothing, every use case is a wallet use
case and this doesn't make sense
Embedded credentials - doesn't know what this means, is it useful? Is it
IoT? Can a scenario be generated?
Both of those use cases may be deleted
More reviews are needed
Discussion about publication of supporting documents:
https://datatracker.ietf.org/doc/statement-iesg-support-documents-in-ietf-working-groups-20230824/

Tim Capalli notes that there might be some way to put digital
credential/wallets into the document and offers help (in the form of a
PR)
Kathleen Moriarty was the lone reviewer and would appreciate having some
assistance in reviewing
Henk Birkholz there will be remnants of this document in the next
document we produce; this will inform the architecture in particular
Shigeya Suzuki asks about the embedded use case and we learn that Brent
doesn't know what it means, but is open to ideas
Rohan Mahy said something but the audio was awful

Traceability Claims

https://datatracker.ietf.org/doc/html/draft-prorock-spice-cwt-traceability-claims

Brent Zundel

Brent explains how there are lots of terms in use when it comes to
traceability, but there is a risk of divergent use. Lots of active work
in the area. No JWT/CWT claims in some cases where there is described
actions. Document is a way to document a few new claims that represent
things that show up in trade documents. Desire to better describe supply
chain actions as well as objects (e.g. organic blueberries, temperature,
and weight).

Yaron Sheffer it is strange to have claims that don't include units.
Brent explains that the unit is specified for each of the claims in the
definition of the claim.
Rohan asks for more description of the semantics. ADvocates for breaking
things into groups. Temperature is handling requirements. There might
also be temperature logging for the monitoring system. There might be
g-force limits for handling as well. A bit of a hierarchy might help.
Instead of just a linear list. Would like to see examples discussed, but
don't see this as necessary before adoption.
Peter Liu has worked on traceability. Some information could change over
time. The number one thing is the endorsements that apply. You might
need to split information between what is static and what is changeable.

Mike Jones is not an expert in this particular area. I did help write
the definitions so that they are unambiguous. I would support adoption
and then have the WG apply expertise to the claim definitions and their
structure. I worked on this because I understand that the authors have
credible experience. Asks Rohan to file an issue.
Henk speaks from experience about SI-units. Lots of other units
(human-centric) are in use and notes that they often require
transformation. Mentions senml that has lots of unit definitions. Lots
of stuff is weird in practice and things need to be copied from pieces
of paper.
Kathleen asks if we have enough people who are experienced in this
domain.
Brent observes that there are several types of documents that are very
common and used in almost all transfers of goods.
Kathleen mentions that she is working with a student who is looking at
luxury goods and supply chain. We may have a random set of what is
brought to the WG and it may be worthwhile to see if we can get a larger
list to see the possible scope and ways to generalize the claim sets.

GLobal Unique Enterprise (GLUE) Identifiers

https://datatracker.ietf.org/doc/html/draft-ietf-spice-glue-id
Brent Zundel

Brent gives a brief recap of where we are. There are too many
identifiers. This maps a small set of identifiers from that space into a
single URN.
More reviews as only one came in since last meeting.

Yaron suggests that maybe we can reserve a space for national-level
identifiers.
Brent notes that this suggestion has come before. The present
identifiers are all global, not national. National namespaces would be
in the tail end of the space.
Mike believes in the efficacy of the IANA process. When this goes to the
IESG, we'll get these registered. Nations are able to register labels
that might correspond to their national systems. We could put
instructions to experts that two-letter country codes are not to be
registered other than by nation states. We should not prejudge that
corporate identifiers are to be bound to identifiers; these are
generally international organizations.
Yaron points out that corporations are often not international.
Brent agrees with Mike generally.
Robert Moskowitz notes that there is a recognized coding in ISO 3166
that describes how to identify countries and their recognized subunits.

Leif Johansson asks what happens when D&B wants to register something in
the URN namespace that conflicts with this identifier. Are they
different? Do they have the same semantics?
Brent agrees that this is a potential problem.
Leif suggests that this might happen. Considers it unlikely that nations
will register. But maybe D&B would think that what we have done is not
right. Maybe we should be sure to be OK that they are OK with what we
have done here.
Brent we defer to these. Have already talked to GS1 and GLEIF, but
haven't talked to D&B, though can try.
Henk indicates on chat that the concept of nations and countries is hard
to grasp in this context.

OpenID Connect standard claims registration for CBOR Web Tokens

https://datatracker.ietf.org/doc/html/draft-ietf-spice-oidc-cwt
Beltram Maldant

Register 19 OiDC claims into the CWT registry is the goal of the draft
One reviewer since the last meeting - Mike Jones.
Heather asks how many people have read it. Asks for reviewers.
Kathleen and Leif and DW will read it and provide reviews.

A reference architecture for direct presentation credential flows

https://datatracker.ietf.org/doc/html/draft-johansson-direct-presentation-arch

Leif Johansson

Leif is not convinced this is a good idea and would like other views.
Feedback requested on:

1. Are the normative claims correct in the architecture draft
2. Can we find a name for the wallet? A technical term, not necessarily
   a marketing term.

Henk recaps: at the moment you don't want to use the word mumbles I
think that you need to distinguish between crypto device from crypto
application. There is an interaction between a human being and the
technology. We might not want to use the word "wallet". There might be
an HSM.
Leif we still need a term. Don't want to tie this to the EU spec. The
ARF is a bit of a mess.
Tim Cappalli the term is not just about credentials, but maybe identity
wallet connects to a "credential provider".
Henk There is an intent here and a capability. Need to understand how
the hopefully-sentient human uses the thing.
Leif concern about conflict with RATS
Theodosios Dimitrakos notes that if this is about the credential
provision, it implies the process of creation and provision. Credential
management agent is fine.
Brian Campbell notes a problem with credential provider in that it is
not analogous to other *** providers in the domain. Agree that wallet
is a terrible term.
Mike from the floor observes that this is a term we have.
Leif acknowledges the -provider challenges
Tim doesn't a wallet replace a provider?
Brian disagrees, but notes that this speaks to a potential confusion.

SPICE SD-CWT

https://datatracker.ietf.org/doc/html/draft-ietf-spice-sd-cwt
Rohan Mahy/Henk Birkholz

Ch-ch-ch-changes
Media type is now sd-cwt
Added sd_aead_encrypted_claims
Protocols aready using AEAD and are well developed, no need to add COSE

Only using algorithms in the AEAD IANA registry to stay with recommended
algorithm set
Martin Thomson recommends using "AEAD-Protected" in chat
There are some weaker algorithms in the registry, so updates are needed
in order to get back to a reliable set. Use AEAD-Protected is the key
take-away.
Changes since last meeting were included on a slide in the presentation.

Someone asked whether the privacy properties with respect to
unlinkability are made worse (or better) as a result of adding
AEAD-protected claims. Rohan responds that there is no privacy
difference (and this is covered by the new security/privacy analysis in
the document)
Rohan notes that he would like use content-format integer values in the
content-format registry. We can't use them in examples until we have
registered numbers for those things. Does anyone want integers in
examples in place of string labels. Any objection to recommending that
people stick to integers.
Mike has suggested this, because it is more COSE-like. You will notice
that for COSE header parameters, for media types, there is the
possibility to use the COAP content formats registries. This would be a
parallel thing to using a set of numbers that can be used in place of
identifier strings.
Rohan says that there is already a registry request. Should we recommend
the use if integers.
Mike says that COSE just allows for both without a particular
recommendation, but we can use numbers in our examples. We can define
the initial set of numbers, because we are defining this registry. This
is the registry for the ... credential types. Maybe we are talking about
something else.
Rohan says that this uses an existing registry in fact.
Mike was talking about the registry in the draft for Verifiable
Credential Type
Rohan notes that this is empty
Mike apologises for confusion
Carsten Bormann points out that "content formats registry" is what it is
called.
Rohan was trying to disambiguate for people, no confusion about what it
is called in the document.