Skip to main content

Minutes IETF118: spice: Tue 08:30
minutes-118-spice-202311070830-00

Meeting Minutes Secure Patterns for Internet CrEdentials (spice) WG
Date and time 2023-11-07 08:30
Title Minutes IETF118: spice: Tue 08:30
State Active
Other versions markdown
Last updated 2023-11-20

minutes-118-spice-202311070830-00

Secure Patterns for Internet CrEdentials (SPICE) BoF
09:30 - 11:30 Tuesday Session I / Congress Hall 3

Welcome and Introduction

Chairs: Pamela Dingle and Hannes Tschofenig
Note Well

Problem Statement

Background information

Market Driver

  • Leif: (starting at slide 9)

  • the focus is only EU market. it is a negotiaiton process between all
    member states and European Commission.

  • legislative context: EU's attempt to build "digital identity
    wallet"
  • Large scale pilots - implementation acts (tech spec masquerading as
    law)

Must be based on standards in ISO or ETSI - they don't have to write the
standards can reference standards produced elsewere
Initially in person in party flow (drivers licence to police officer)
Major driver is web based use-cases (openID for VCI and OpenID for
Verifiable Presentation)
Two work strands on each of the abor[...]?
Wouldn't hurt if EU came out of this with global interoperability.
Ask to IETF community - would like to have foundational standards ready
sooner rather then later.
Focus on issues related to credentials' security and privacy and need to
be worked out.
No time to duplicate other work - happening in other venues (OpenID
Foundation for example)

  • Brent (starting at slide 12):
    We need information signed and secured.
    Common flow (Three party model):
  • HOLDER provides an assertion from an ISSUER about a SUBJECT to a
    VERIFIER.
  • the assertion is issued in a CREDENTIAL.
  • the assertion is provided to the VERIFER
  • CREDENTIALS and PRESENTATIONS are evaluated according to policies

We need better technology that is more secure and more private.

Slide with examples of some technologies (along with rough timeline)

Automated decision making is the focus.

Three party model was well marketed by W3C Work.
What we want to do is take these idea and build upon them and make sure
they are secure and private as they can be.

Selection of proposed work items

Identifier / Key Discovery document

  • Kristina (starting at slide 17):
    Three party model is not what OAuth is chartered to do.

User controlling the keys during presentation that they controled during
issuance.
Not only usage with "natural persons" but also "legal persons"

Pros and Cons (slide 19)
some use-cases require history of the keys.
not .well-known paths for finding keypair
there is something in /JWT-issuer

No off the shelf interop with DIDs => hesitation from implementors.

Identifier and key discovery mech
How get keys and how trust is established.

Technology Driver

  • Orie (starting at slide 23):

Also trade information. Securing cyber physical supplychains, and trade.

need for concise representations (as data can quickly inflate)

Issuer claims about subject.
(Holder is not always subject)

data presentation needs redaction to only reveal the minimum amount of
information necessary to take decision

with traditional signature schemes you have to present the entire
payload.

selective disclosure is a fundamental building block for all this work
(balance the needs of business and the needs of individuals)

decrease the secruity and privacy issues by working on selective
disclosure from the beginning, along with unlinkability.

Selective disclosure in COSE instead of JOSE. Binary doesn't have to be
text encoding. Important when you have nested structures.

Familiarity with JOSE development systems. Then started to use COSE
strucutres. Synergy and alignment is a good thing.

Selective disclosure structure (SD-CWT) (slide 26)

challenges in presenting in JOSE that COSE doesn't have.

SBOM (Software bill of Materials) use case: Work within SCITT working
group on securing software supply chain. SBOM has been in the news -
tells you what went into the software. Tells you all the places that
need to be fixed if something is wrong.

Example SD-CWD SBOM payload structure uses 222: label twice as the
locations where we put the binary representation of the disclouse

Privacy: Selective Disclosure and Unlinkability

  • Mike Jones (starting at slide 29)

Asked to talk about Privacy.
We could build identity system where people asked for information about
you - they got all the information about you. Motivation is to do better
then that.

privacy = minimise disclosure

enablers: OpenID connect claims request parameters, SD-JWT,
ISO mobile Driving License (mDL)

privacy = not "calling home"
can use physical plastic card to buy alcohol and to board an airplane -
the card does not contact the issuer.

OpenID Connect and SAML do call home. the IDP knows where you ask.

VCs don't "call home"
Wallet can see where you use them - not the issuer.

Privacy = non-correlation amongst verifiers.
Work on BBS going on in CFRG to enable ZKP

Prevent correlation between issuers and verifiers.

Trackers and what they do with the information.

Privacy = Releasing Proofs rather then claim. BBS+ work can do this.

Clarifying Questions

  • Manu Fontaine: ?

  • MCR (question for Leif): the extent to which using smart-phones is
    important?

    1. Person to person adjacent.
    2. Expectation that my credentials that are connected to TPM.
  • Leif: Not just for smart phones.

  • Roman (question to Orie): I observe in many cases this JSON vs CBOR
    thing - why you think it's more complicated in JSON? Could we have a
    single CDDL that produces both JSON and CBOR serialisation of the
    same info model?

  • Orie: need to harden JSON Base64 serialization unicode encoding
    matters. When you create signature with constraints building on of
    it you encounter
    Protected header,
    SD-JWT - JSON, JOSE - append to string with Tilda - JSON
    serialization in unprotected header. Mirror
    JOSE and COSE are typically aligned - but some times not. Preserving
    privacy and security.

Charter & Milestones

TL;DR (by IdentityWoman)
We are creating a venue for individuals who really want to work on
verifiable credential stuff at IETF.

Charter discussion started already (see
https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md).
Got already some feedback from Roman (thought there's more!)

Selective disclosure unlinkability.

The charter as currently drafted says: "protocols are out of scope."

We hope that protocols will be independent of the data representations.

The starting working set is:

  • informational doc architetural
  • PS doc for selective disclosure using CWT
  • PS doc for unlinkability with CWT
  • PS doc for identity docs with CTW

Always go where the experts are. This meeting has 150 attendees!

Discussion

Direct presentation is over.

  • Dmitri Zagidulin: who came up with the SPICE acronym? A: Orie
  • Say more about extensibility. Extension points to do other thigns
  • Henk: Digital drivers license. Problem QR codes kind of same thing.
    Records I've done some bad thing - require expiry of disclosure
    after a while. International interactivity. Passport analogy - going
    somewhere presenting. What does immigraion desk - want to enter
    country without bias. (ideal world) all items could be achieved with
    subset.

  • Dmitri Z: How is that extensibility

  • Henk: extensibility you need more characteristics - algorithems to
    disclose or undisclose - there are different algorithms in different
    jurisdictions.

  • Bob M: dragged kicking and screaming into world of Aviation (ICAO)
    get to certificate authority for digital passports (PKD) if you are
    talking about how passports get into this - x509. 10 years and the
    craft is moving - see how this works with it. To roll roote
    certificate on aviation fleet is 3 years.

  • Hannes: soungs like good input into the architecture: separtion of
    credentials from protocols. they will need to be mixed - interactive
    selective disclosure. presentation disclosure to survey them.

  • Kristina: Straight forward answer Building protocols natural persons

  • Jonathan Hoyland: Had quick read of charter - should work with all
    these working groups - one left out - PrivacyPass, why?

  • Brent Z: We forgot.
  • Manu Fontaine: Good introduction. Focused on privacy very important.
    Wanted to bring work of confidential computing verifiable software
    on verifiable hardware - develop software agents cryptographcially
    bound to entities. You can have agents that talk to one anther do
    exchange of data that is invisible from humans - encrypted and
    protected. confidential-computing agents can enable some of the use
    cases discussed by doing the needed computation in a trusted
    execution environment that is privacy and confidentiality
    preserving. assuming such computing environment simplifies the
    architecture greatly.
    Intersted in contributing to group.
  • Hannes: compared to just a few years ago, we now have technology
    that enables new capabilities that allow us to store credentials
    more securely.

Cedric Fournet: question about scope: the idea of separating credentials
from protocol. this seems not really possible in certain flows.

Kristina: at the moment there is no clear winner in the credential
format space. aim at consuming credentials created in other groups
(e.g., SCITT).

Shiigeya Suzuki: why discovery is out of scope?

Kristina: discovery, key resolution, authentication...

Hannes: the "identity documents" will deal with this -- we didn't forget
about it.

Orie: Privacy pass: As I prepared slides on how IETF - privacy pass was
missing. unlinkability as property good pieces in both (Oauth)
non-natural person identity machine identity and bot identity and some
of what privacypass has been doing is very interesting and we need to
include it into the work.

Roman (as individual): clear about info/data model building blocks but
currently confused by the sections of the proposed charter related to
the identity work. in particular, the statement "no protocol work". how
is discoverability, which looks like proper protocol work, going to be
taken care of?

Leif: maybe word "protocol" gets us into trouble - many aspects of
protocol do apply. Transport protocols are out of scope - way credential
gets from issuer to holder and holder to verifier.

Roman: when I read a transport protocol I don't think of that.

Hannes: privacypass has many elements to it.

Daniel Kahn Gillmor: some transport protocols have linkability problems,
thus privacy impacting. It seems odd to keep those out of scope.
Discussion in a chat - what to people do who don't have devices. Things
deployed at scale for getting around society. Sometimes you run out of
batteries. Avaliability - offline paper credential usecases - some of
theings we want are not possible with offline or paper use-cases. What
to do without a device.

Leif: yes, I agree with DKG these are important problems.

Kaliya Youg: People are working on cloud based wallets may be a solution
to the problem DKG highlights

Denis Pinkas: there are predicate proofs that are also possible. you
need to support protocols in addition to data structure.

Hannes: architecture doc contains vocabulary, roles and conceptual
messages flowing between the identified roles. many instantiations are
possible. no need to be religious about that.

Justin Richer: I got in the queue to raise question about protocols
being out of scope. What is the plan for all the things this forum deems
out of scope. lots of need to liase with - so work does go to the right
place. "says VC" so it goes in spice. We will have to put in the
charter.

Hannes: we need persons from other SDOs directly in the WG room/ML vs
official liasons. it simplifies the information flow a lot.

Oliver Terbu: there is a significant overlap between OAuth Experts and
SPICE work - conceptual overlap between CWT documents and SD-JWT VC work
that was just adopted after IETF 117. Issuer discovery and validation,
e.g. using DID, x509 etc. I agree that presentation exchange should not
be a priority but don't agree that other protocols should never be in
scope. For example, issuer key discovery could be inscope.

Hannes: key to have alignment.

Nick Doty: CDT there has been some discussion of privacy and it is
concerning that we fogot other groups that work on Privacy good to be
consider selective disclosure and unlinkability - and concerned only
asking about any other privacy properties - transparancy, control,
accountability. Do we think we about places this technology is misused
and how it will be mitigated. Worried about a "papers please internet"
wehre must preset government paperwork. Not just there is an EU law and
we better do something.

Hannes: Gave Mike 10 min and didn't cover full bredth. Please bring
these additional considerations

Orie: I work on transparncy services for sofwtare usecases. I find
interesting - duality between transparcny and unlinkability -
unlinkability with a special kinds of transparancy. Have we thought
about all the ways - no. Excited about the convergence of transparency,
unlinkability and ZKPs. Having a place to talk about risks to talk about
design principles. Shares concern about 'papers please' cautious about
world where this was rolled otu everywhere. IETF organs like IAB can
address concerns. +1 to your concerns

Manu: Think of introducing confidential personal agent verifiable piece
of software to what is happening. Issues get resolved.

Kristina: Stab at what Justin mentioned that is out of c
ISO, IETF, DIF, W3C, OpenID Foundation I have some claim to
understanding
RDF is out of scope.
Has to be defined better focus on 3 party model.
Better stab Leif: differentiating transport protocols from credential
formats.
Data person is attesting about a
How the keys to verify that is not always in scope.
Transport is more exchanges with query languages - defining a new
transport protocol should be out of scope. Refering to them in an
architecture document they could be mentioned.
Anything that fulfills requirement.
Getting this 3-party model right is very hard. Not going to be perfect
we have been working on it for 6 years.
A lot of it is regulations and requirements from that.
If we will wait for the best ZKP algorithms to come to completion and be
ready to be deloyed at scale. Balance with what the technology can
actually do.

Leif: Address nick's concern "papers please internet" I never found that
we were getting technologies so simple - overly deployed. What we are
building EUDI wallet space. simple show licence to show practice nursing
in a different country. To your point Roman the verticals will be
represented - university educational credentials, K-12 credentials,
labor market, social security are specific usecases in large scale
pilots.

Roman: is the IETF creating building blocks for other to creating the
protocols or is the IETF taking care of the protocols itself?

Leif: the former (building blocks) - so it can be globally interoperable
and privacy preserving

Geovane: interest in compact identity documents for IoT scenarios

DKG: push back on the idea that we need to depend on the regulator to
make the accountability mechanisms. we have an obligation to provide
hooks for accountability, especially for verifiers and issuers. we need
to protect the holders who are the weakest in the 3-party model.

BoF Questions

  • Chairs / Area Director (Roman):

Hannes: Where do we go from here? The charter text is not yet there
(clarifications around protocols, language around privacy, etc.). We
need to get the sense of the room now.

From RFC 5434:

  • There is a problem that needs solving, [...]

Yes: 85
No: 5
No opinion: 66
Participants: 157
(one double vote?!)

A clear yes. Some of the "No" wants to provide a reason for their no?

Nick Doty: I voted no because I don't understand what is the problem we
are trying to solve.

  • [...] and the IETF is the right group to attempt solving it.

Yes: 69
No: 4
No opinion: 84
Participants: 158

Mallory Knodel: there is work ongoing in other SDOs (e.g., W3C) I am not
comfortable with that.

Rifaat: so many "no opinions" because people do not understand exactly
what we are trying to solve

Hannes: reminder of the scope (CWT based building blocks)

  • The scope of the problem is well defined and understood, that is,
    people generally understand what the WG will work on (and what it
    won't) and what its actual deliverables will be.

Yes: 24
No: 57
No opinion: 74

Hannes: a bit in contraddiction with waht we had initially. This seems
like the problem statement is not as crisp as it needs be.

Guilin Wang: no familiarity with the voting tool: can the chair remind
especially the remote participants how one votes?

Hannes: explains quickly how the vote works

Carsten Bormann: the problem is huge, and I don't understand the whole
scope. the problem is so big then it would be realy weird if I did
understand it.

David Waltermire: Milestones written in a fairly abstract way didn't do
a deep review of charter and more review.

Hannes: Responsibility for participants to look through text. For me the
milestones for what they want to work on. Unlinkability for JSON work is
also avalialbe should give you a good idea where this is headed. Point
taken.

Manu: I said Yes, Yes, No. There is a problem that can be tackled. Tech
has evolved a lot, and there are now computation primitives to do solve
some of the underlying problems.

Wrap-up and Conclusion

Roman's observations:

  1. lots of people in the room (which is fantastic)
  2. question about whether there is a distinction between what we have
    talked here with work already in flight in other WGs (e.g., OAUTH)
  3. based on conversation and engagement: there is definitely work to be
    done and energy to do the work
  4. there is currently some amount of mismatch between scope and problem
    statement: the charter is not a crisp enough description, it needs
    to be refined. We need to go back to the ML and discuss the charter
    until the scope is defined well-enough so that we can start doing
    actual work.