Minutes IETF122: spice: Tue 08:30
minutes-122-spice-202503180830-00

Meeting Minutes Secure Patterns for Internet CrEdentials (spice) WG
Date and time 2025-03-18 08:30
Title Minutes IETF122: spice: Tue 08:30
State Active
Other versions markdown
Last updated 2025-03-18

minutes-122-spice-202503180830-00

SPICE

Agenda

Welcome & What is SPICE - 10 min (chairs)

Document Discussion - 40 min total

Welcome & What is SPICE - Chairs

Note-Well and processes.
The slides are really colorful and are worth checking out.

SPICE SD-CWT - Rohan Mahy

slides

Recap of the selective disclosure

Intro

  • Add decoys
  • Definition of map key in CWT is being updated, so that every SD-CWT
    is a valid CWT, but not vice versa

Martin Thomson on chat: What is a decoy is not a decoy?

Discussion on what can be disclosed, and their format

Disclosing to a verifier, presentation of the process

The Holder can also prove possession of a private key via bindings.

Disclosures can be nested, even though this imposes a structure on what
has to be disclosed (parents to disclose a children)

Justin Richer: When you disclose something nested at a lower level, do
you have to disclose the entire object structure?
Rohan Mahy: You currently need to disclose the path, and redacted
versions of the siblings. The structure may have to be disclosed. The is
an example in the draft with a set of inspection certificates.

Changes since the last IETF (121)

New normative changes

Using simple value, no enclosing around sd_claims

AEAD encrypted disclosures motivation is because some verifiers have
internal structure, and only want to disclose part of it (RATS, MLS).

All examples have been regenerated. If you have an implementation, look
at it.
There is a new Rust 🦀 implementation in the implementation section

Open issues

No open PRs, multiple issues that could use discussion

Henk Birkholz: Ordering in Rust is simple, but that's a consideration
for implementations
Rohan Mahy: This is up to your language and types

Next steps

Continue working on open issues
Update implementations
Interrop testing
Looking for WGLC

SPICE GLUE - Brent Zundel

slides

Why GLUE identifiers? We make online statements about organisation, and
need a consistent way to identify these orgs. There are multiple ID
schemes, and some of our data models require URNs.

What is a GLUE Identifier? A URN with context instead of an ad-hoc
identifier.

Changes since the last IETF (121)

  • Have a dedicate glue namespace urn:ietf:spice:glue

Rohan Mahy: I would like to have the "thing" after glue to be a reverse
domain name so there is no ambiguity
Justin Richer: I disagree with Rohan. I think we want something closer
to airport codes, because domain namse change, TLDs disappear. They are
not stable. Because this is a new namespace, it faces the same problems
as every new namespace: name squatting, meaning overlap
Brent Zundel: The draft has language for that
Michael Jones: IANA is usually the place to disambiguiates, we don't
have to do something special for this registry
Christian Amsüss: Should the namespace stay when any new GLN is already
in the URN namespace?
Brent Zundel: You can shorten it in your application by omitting the
initial reference urn:ietf:spice:glue, up to your implementation.

Working group adoption? Email to be sent to the list
A couple of implementations are in progress with people using them.
Michael Jones: Should we use the IETF show of hands tool with a show of
hands?
Martin Thomson: Start a show of hands. Result 16 yes 0 no 1 no opinion

OpenID Connect standard claims registration for CBOR Web Tokens - Beltram Maldant

slides

Registering 19 claims from OpenID Connect claims in CWT. Refer to the
slides for details

Since the last IETF (121)

  • Added CDDL
  • Has been reviewend by IANA
  • Turn address into CBOR mapping

Next steps

  • Expert Review
  • WG adoption? Someone wants to go fast because it's a straight
    forward topic

Rohan Mahy: This is super useful, and for an example I wanted to put
with an address, I used this one. I'm in support
Michael Jones: These claims are used in the real world for JWT already.
I support adoption
Richard Barnes: I support adoption

A Public Key Service Provider for Verification in Multiple Issuers and Verifiers - Donghui Wang

slides

The verifier uses the public key of the issuer to validates claim from
the holder. This becomes complex with multiple issuers and verifiers
given everyone may be an issufer and verifier.

Note from the notetaker: the slides have a lot of diagrams, I invite
the reader to look at them on the side of these notes

The trust relationship is not a 1:1, but becomes a 1:many. This document
introduces a Public Key Service Provider (PKSP). When the verifier
requests a public key, they are ask the PKSP that would provide the key
on behalf of the issuer.
This can be used in blockchain applications.

Future work

  • PKSP design decails

Justin Richer: Doesn't it replaces the trust from multiple issuers with
the trust in the key provider? What does this one layer add?
Donghui Wang: When you need a lot of public key from a lot of issuers,
this helps with the discovery of these public keys
Justin Richer: Wouldn't you have to trust multiple PKSP then?
Donghui Wang: Possibly
Richard Barnes: This is a problem that has come up multiple times. In
the past, we had things like bridge CA that would connect multiple PKI
together to expand trust to different domains. OpenID has HTTPS based
discovery, which is also a public key distribution system. It's
decentralised, there is no central entity/blockchain. Before we dive
into these design with web3, it's be good to understand why the existing
mechanisms don't work

Updating use case draft - Brent Zundel

draft

As soon as the deadline freed, I uploaded the new draft. Have a look at
the use case draft.

We originally had use cases we wanted to fill out, and they have been on
top of new use cases.

Michael Jones: There are multiple documents with a single author, or
authors from the same company. You should be ok with having more
authors.
Rohan Mahy: The same example may be explained in different context. We
have one in our draft.

AOB

If people are interested in an architecture document, we can gather them
to have one. This can be helpful for current and future reference.

Henk Birkholz: This is actually a deliverable in the charter
Martin Thomson: This is something many WG have attempted, and it's hard.
Let's make sure there is a protocol at least.