SPICE BOF - IETF-119

Chair: Hannes Tschofenig, co-chaired by Paul Wouters

Notes: Yaron Sheffer


Welcome (10 min, chair)

Had ongoing charter discussions since IETF-118, comments from non-IETF
experts, also published several drafts.
The goal is to agree on the charter text today.

Architecture (5 min, Henk)

https://datatracker.ietf.org/doc/draft-steele-spice-transparency-tokens/

https://leifj.github.io/wallet-refarch/draft-johansson-wallet-refarch.html

Two viable input docs are the basis for an architecture document. The
basic architecture (Escher diagram) is given in the group's charter.

Richard B.: interest in pulling credentials (and proofs) into other
protocols.

Use Cases (15 min, Mike + Brent + Roy)

https://datatracker.ietf.org/doc/draft-prorock-spice-use-cases/01/

Version -01 published before the cut-off.

SD-CWT (5 min, Orie)

https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/02/

CWT might be more practial than JSON, from a performance POV.
Selective disclosure is not new, already done by mDoc (and similar to
SD-JWT).
Orie discusses receipts and the security guarantees they provide.

Mike P.: huge amounts of legacy data, detached sigs are needed to bridge
legacy docs into the new creds. COSE/SD-CWT is well suited. An SD-CWT
can secure a file by value or by reference.
RB: how do we keep SD-JWT and SD-CWT in sync?
OS: we have to be cautious when porting features between the two, might
have subtle security implications. But there are going to be
differences. We should keep them conceptually aligned.
Justin R.: is there design to pull JOSE versions of artifacts into this
group?
OS: OAuth WG is managing these documents. No plans to move anything.
Hannes: this was discussed. The conclusions for now is to keep the docs
in OAuth.
RB: Better to have all the credential stuff in one location.
Hannes: maybe in future.
Roy: resistant to having all the docs into one group.
OS: security considerations should be aligned or at least considered
across the two versions.
Henk: comms channels are there.
Martin T: diversity of use cases, broad applicability. There are going
to be one or two formats, and these should be owned by one group.
RB: these are analogous to certs. Let's do the 2 common formats in one
place.
Hannes: we already have the 2 formats, to a large extent.
JR: Is the group "vertical", focused on one tech, or horizontal, focused
on the multiplicity of use cases. The charter reads more like the
latter. SPICE should work on reusable containers. There are existing
VC-related docs that are looking for a place to be dispatched to.
Hannes: not a 1:1 match.
JR: "the Internet has reinvented certs, now called VCs." This needs to
be the hub of expertise for that. SD-JWT-VC is very specific to VC.
Hannes: let's defer this discussion, and go back to where we thought we
had agreement.

Meta-data/Capability Discovery (5 min, Orie)

https://datatracker.ietf.org/doc/draft-steele-spice-metadata-discovery/01/

Charter Text Discussion (All)

Brent Z.: agree with RB and JR re: the horizontal nature of the group.
He chairs the VC work at W3C and would love to discuss the relation
between the groups. W3C still doing JSON-LD, decided not to address
other tech. SPICE will be doing similar things with more IETF-native
tech.
Rohan M.: 4 levels deep in details, unnecessarily. The charter does not
define a good scope. E.g. confusion between human identity vs. other
things being identified.
Hannes: we need to form a group to do this work.
Rohan: maybe define an initial list of 3 subject types...
Brian C.: metadata discovery is very much about key discovery, which is
supposedly out of scope.
OS: this was discussed on the OAuth ML, and the scope was handcrafted
accordingly.
BC: SD-JWT is not unlinkable. The charter tech is overstating it.
Mike P.: once we start we can narrow down the scope. There are already
working implementations.
Mirja: would like to understand the relationship with W3C better. How
much coordination?
Brent: dependency is conceptual. No intention in SPICE of using the W3C
data model.
Mirja: both group will develop things independently?
Brent: in theory, yes.
RB: we should not expect technical interop with W3C VCs.
MT: as liaison to W3C, concerned that it is not mentioned in the
charter. Better to have clear delineation. Selective discolure is fine
but unlinkability is something else, and not described in the charter.
OS: the primary difference with W3C work is at the data model layer.
Cullen J.: the charter looks like venue (SDO) shooping. We should not
ignore it in the charter. The scope is not clear: which VCs we should
look at.
RB: PKIX is similarly broad - a secure container.
Brent: still thinks the 3rd version of the charter is good. We have to
stop churning.
Mike P.: there is clear delineation. Need to do some of this stuff
without JSON-LD, and at the binary level. We are testing stuff now, need
interoperability.
Manu F.: I'm a contrarian... Support the idea of Internet creds.
Bothered by having key mgmt out of scope. Had a side meeting to discuss
this point. We should move forward.
Mike J.: this work meets the criterion of addressing a real use case. To
Cullen's point: doesn't see this is venue shopping. Binary sigs is
different from JSON-LD.
RB: addressing diff from W3C would help clarify scope.
John: clarify that this is not RDF (unlike W3C). This work is needed
urgently.
Yaron S.: this should be a community for VC work at the IETF. The
charter is clear on the technical side but not on the business side. In
particular human vs. non-human identity. They have different tech
implications (privacy vs. transparency, extensibility+profiling)
Carsten: we will be inspired by W3C work.
Roman proposes a sentence about relation with W3C work.
Ray L.: this would be good for election security. Worried about key
discovery - is it in or out. Metadata OTOH is a quagmire - see RDF. Need
a bucket for metadata - extensibility by other orgs.
Rohan: is there a GH repo for the charter text, to send PRs? Room: it's
in the chat.
John: proposes text changes.
Mike P.: general agreement about the deliverables, let's move forward.
Poll: v3 of the text plus Martin's text (SPICE will develop designs that
follow the conceptual security model that is used in W3C VC, ISO mDocs,
blah, . SPICE will not seek to extend or integrate any of those specific
technologies.) - Y 40/N 1/No opinion 9
Hannes: we will ship the charter with MT's change to the IESG.
Manu: there are always privacy concerns, even for non-human. We should
address non-human IDs.
Nick D.: still concerned whether this will be used in a privacy
respecting way vs. used for surveillance. Venue shopping increases the
risk of harmful use.
Hannes: made specific changes to the charter text to address these
issues. Including privacy language and mention of related technologies.

Nick: while we mention the right tech, there is no strong requirement on
privacy in the charter.
Paul W.: happy this is finalized, now goes into IESG review.

Link to all the poll results:
https://datatracker.ietf.org/doc/polls-119-spice-202403191300/