SPICE WG - IETF 120

Agenda

Thursday, 25 July - 17:00-18:00, 18:30-19:30
Welcome - 5 min (chairs)
What is SPICE and Why Are We Here - 20 min (chairs)
SPICE and WIMSE - 5 min (Justin/Pieter)
Document Discussion

• https://datatracker.ietf.org/doc/draft-steele-spice-profiles-bcp/ -
  15 min (Mike Prorock)
• https://datatracker.ietf.org/doc/draft-prorock-spice-cose-sd-cwt/ -
  15 min (Mike Prorock)
  BREAK
• https://datatracker.ietf.org/doc/draft-steele-spice-metadata-discovery/
  • 15 min (Orie Steele)
• https://datatracker.ietf.org/doc/draft-zundel-spice-glue-id/ - 15
  min (Brent Zundel)
  Other Business - 10min (chairs)

Minutes: Session 1, 17:00-18:00

Introduction and Administration

• Heather Flanagan: Note Well and background, meeting tips, etc.

• Brian Campbell: Concern that the discussion and PRs from the charter
  discussion were not included in the final version. The process seems
  to have fallen apart.

  • Martin: we will review the PRs and work with the Sec AD on next
    steps

• Martin Thomson: Would like input from the working group on how we
  will use GitHub and the mailing list.

  • Administrative items (e.g., calls for adoption, WGLC) to be done
    on the mailing list
  • Technical discussion of documents to be done on GitHub
  • Drafts to be added to the WG repository when adopted by the WG

Action items

• Chairs to review PRs with Sec AD and either accept them or start a
  recharter process
• Chairs to confirm working group process wrt GitHub, mailing list on
  the list

SPICE and WIMSE

• Pieter Kasselman (filling in for Justin Richer): wimse is a new
  working group focused on workload identity. Their use cases should
  inform spice, and their specs expect to consume the outputs from
  spice

SPICE Use Cases & Profiles

draft-prorock-spice-use-cases

• Mike Prorock: What started the effort to form this group was a
  discussion about how can we document and define use of three party
  model credentials. Existing efforts focused on human-in-the-loop
  efforts that naturally focused on privacy implications. There is a
  need for something that also focuses on machine-to-machine use
  cases.
• Roy Williams: being clear on use cases is really helpful as it helps
  clarify requirements
• Justin Richer: documenting use cases is critical. Publishing those
  use cases as an RFC is not a good idea. Suggest instead: adopting
  the document as an eternal ID; put everything into a working
  group-controled wiki; or have somebody put it on a web page
  somewhere.
• Henk Birkholz: agree that we need to publish use cases somewhere.
  Disagree that this is because use cases change over time. If the use
  cases has changed, the requirements have changed.
• Q: Reminder of the WG-adopted informational status in the
  Datatracker, an explicit marker that this document will not be
  published as an RFC, but it is adopted by the working group as a
  useful document to inform its work

Action items

• Chairs to confirm adopting the use case draft as a WG doc on list

draft-steele-spice-profiles-bcp

• Mike Prorock: Orie's fault that "BCP" is in the title. Goal of the
  doc is to provide regulators and businesses clearer guidance on how
  to use the specifications we're defining and separating the code
  info.

• Justin Richer: Why is this spice-y?

  • because it's directly related to credentials we were working at
    and is tied to our use cases

• Justin Richer: Creating generic systems types (e.g., the DID work)
  is hard to get right and achieve consensus. How will this be
  different?

  • the draft doesn't create a systems type; it refers to prior work
    for that. We're focusing on what the basic things are that
    policy people need to describe are there and how to use them
    appropriately.

• A.J. Stein: Will read the draft. Suggest talking to people outside
  the credential space (e.g., NIST)

  • have spoken with people outside the credential space but would
    love further review

draft-prorock-spice-cose-sd-cwt

• Mike Prorock: Goal is to introduce SD-CWT, a type of CWT (CBOR Web
  Token) that supports selective disclosure, enabling data
  minimization by allowing specific claims to be disclosed only when
  necessary.
• Rohan Mahy: This is an important building block and something the
  group should adopt. Will help.

• Yaron Sheffer: Supportive of the document but would like clarity
  about the non-redactable flag

  • the issuer can specify that certain things should not be
    redacted

• Brian Campbell: Why specify this when the ISO mdoc already defines a
  kind of token which offers selective disclosure and proof of
  possession type semantics in CBOR with COSE signatures signatures?

  • the ISO doc is behind a paywall; cannot review those docs
  • wg members who have access to the ISO doc are encouraged to
    review and consider where there is overlap

• Kristina Yasuda: Also question why mdocs don't meet your use cases.

Action items

• Chairs to send a working group adoption call to the list
• WG members encouraged to review the draft against the ISO mdoc spec

Minutes: Session 2, 18:30-19:30

draft-steele-spice-metadata-discovery

• Orie Steele (no hats): there is are a lot of discovery mechanisms
  across various IETF working groups; maybe one is needed for spice?
  The goal would be to develop a mechanism for discovering credentials
  and capabilities associated with well-known digital resources.
• Justin Richer: Highlighted the importance of discovery for
  translating memorable inputs into complex outputs. Stressed the need
  for clarity on what the discovery system's inputs and outputs are.
  Emphasized the inevitability of multiple discovery systems and the
  importance of understanding and managing their incompatibilities.
• Mike Prorock: the draft's focus on JSON is interesting but maybe
  incorporate more CBOR to align with SPICE's goals.
• Leif Johansson: suggest you engage with experts on OpenID Federation
  to understand how it might relate to SPICE. We need to separate
  discovery from trust establishment.

• Watson Ladd (Akamai): Concerned about the practicality of discovery
  in dynamic environments, such as changing credential validity during
  transport.

  • agreed. It's important to consider system configuration versus
    runtime discovery.

• Justin Richer: there are potential privacy violations from discovery
  mechanisms.

• Heather Flanagan (chair): doc isn't ready; if you are interested in
  helping work on it, please contact Orie or Mike

Action item:

• WG members interested in developing this further should reach out to
  Orie Steele or Mike Prorock

draft-zundel-spice-glue-id

• Brent Zundel: introduced the need for identifiers for businesses,
  emphasizing their importance in supply chain tracing and corporate
  identity verification. Proposal is: The Glue Identifier (Glue ID)
  format: glue:authority-id.external-number. Example:
  glue:irs-ein.54-1650477. Adds explicit authority context to a
  business identifier, making it clear and traceable.

• AJ Stein: Why are existing identifiers like IANA's PENs not
  sufficient?

  • Roy Williams: the scope of identifiers needs to cover a wide
    range of entities, including those without U.S. entities or
    computers. The scheme needs to allow flexibility worldwide.

• AJ (Follow-up): If this requires registration with IANA, that might
  be a problem.

  • The Glue ID aims to provide a flexible and widely applicable
    solution, recognizing different authorities and their specific
    needs.

• AJ: What is the scope of enumerating different identifiers?

  • Mike Prorock: The system tracks over 200 million unique
    businesses, accounting for various identifiers required by
    different jurisdictions and regulatory purposes.

• AJ: What about the privacy concerns associated with certain
  identifiers, such as taxpayer identifiers for sole proprietors?

  • Please raise the issue for further discussion, we need to
    address this

• AJ: How does the system handle nested organizations and confidence
  in subsidiary relationships?

  • The draft describes a string identifier as a building block,
    with future layers handling more complex relationships and
    attestations.

• AJ: Can arbitrary organizations mint these identifiers?

  • The registry aims to include well-known organizations that
    identify businesses, but flexibility allows for new authorities
    to be recognized based on trust and context.

• Heather Flanagan (chair) : How does this fit within SPICE?

  • The Glue ID provides a unified way to refer to companies,
    aligning with SPICE's goal of managing credentials and
    attestations about entities.

• Brent: Doc isn't ready for a WG adoption call but would like to
  discuss further