SPICE WG

Early Meeting

• Call to Meeting
• Rules and Introductions
• Brief Intro to SPICE
• Disucssion of Agenda

Use Cases Document

• Brent Zundel presents on use cases document that is being published
  by the working group.
• Tony Nadalin has provided a use case for digital credentials.
• Mike Jones added as author.
• Tim Cappalli given open review task.

GLUE Identifiers

GLobal Unique Enterprise (GLUE) Identifiers

• Draft available here with Brent Zundel leading in person
  discussion.
• Allows for organizational namespacing. We need to identify
  organizations, GLUE potentially provides a way to identify those
  orgs via URN namesp

Q&A around explainer

• Orie Steele: Is it possible for vendors to register their businesses
  within another authority? Is it possible for me to do this?

  • Brent: Yes, as long as that scheme is globally unique

• Tim Geoghegan: Do i need to provide an identity to

• Henk: The G in GLUE is not getting enoug attention, in that it seems
  like it could be geolocation, which might not be unique.
  • Pamela Dingle: the goal of GLUE is to provide unique identifiers
    of an organization, it's not geolocation or dependant.

Discussion around URN Structure

Chose namespaces

Q&A on

• Rohan: We should put ietf in the URN so people know where to find
  additional information

  • Tim: We should try to make it short as possible and learn toward
    urn:glue
  • Mike Jones: Just use urn:glue
  • Orie agrees

• Werner: I'm confused because we already have a namespace for LEIs,
  and so if we're going to use a namespace for this let's use the
  namespace that already exists. Also, the namespace should provide
  information about what the URI is being used.

  • Brent: do you think that the identifier needs to include
    information about its use? Currently the specidi
  • Pamela: The whole reason this exists is not just for those that
    store LEIs. There's a pretty good test: is it bi-directional?
    Can an LEI be used in your GLUE uri, and if not then you should
    restrcture.

OIDC Claims Registration

Beltran Maldant presents

• Trying to register 19 Claims from the OIDC standatid claims in CBOR
  Web Tokens to IANA registry

• Since Madrid...

  • addtional birthdate rules
  • updated_at as JSON number
  • better definitions around #_verified claims

• Two questions for the WG on issue #26

  • How do we sync changes or additions to OIDC IANA registry?

    • My recommendation is that we don't sync changes and deal
      with it as it comes.

  • How could we have a shared IANA registry for both JWT & CWT
    claims

    • There's not 1:1 JWT:CWT mapping so it might be hard to
      maintain

• Mike Jones: You're right, OIDC is final and not going to change.
  Also when we began building the CWT registry, we mentioned that they
  should attempt to correlate with the JWT claims. As for a shared
  registry, it shouldn't be the job of this draft to register those
  claims

• Questions around issue #25

  • Should this claim be the End-user's defined gender or the gender
    outlined by OIDC recommendation
  • should we keep recommending something or should the user choose
    what to put in that?

  • If we recommend some values, and we're using CBOR,should we
    assign numbers for genders?

    • I'm not trying to create the gender registry in CBOR!

  • Rohan: You're right to call out the semantics here and that's
    the best way to approach this. This is insufficiently
    complicated as a structure to convey the medical definitions of
    biological sex and gender. The only thing that I can think of is
    to say that it's up to the issuer to define what it is, and
    people will know from specific issuer's (i.e. governments) what
    their options/values are.

  • Mike Jones: The goal of this draft is to re-register specific
    claims for JWTS and CWTs, and not just for this but i've said in
    the past that we should make them exactly the same between JWTs
    and CWTs. I have an open PR that reflects that. Rohan calls out
    a good point that some of these are ambiguously open, and
    slightly open for interpretation.

    • Beltram: so what about for concise representation?
    • Mike: that's mostly for interop, but it's not i18 specific,
      in that different languages and countries might use
      different identifiers

  • Wendy: it's important to give humans the choice

  • Justin: We shouldn't lean on decisions we've made in
    specifications long ago to do something one way. We should be
    allowed and able to get better. I do really like adding the text
    that this is really only defined in the context of the issuer.
    Also, it is very difficult to define the societal differences
    between sex, genomic sex, gender, etc through.

    • You suggested the addition of text? Text in this field?
      -Justin Richer: Yes but could be done elsewhere

  • Kathleen Moriarty: I think we should handle this the way we did
    in the IETF previously, we used to be very clear that the IETF
    is just defining something for technical implementation, and if
    it gets construed as a legal or political statement, that's out
    of scope.

SPICE SD-CWT

Rohan Mahy discussing changes since IETF 123. THere have been 4
normative changes and 5 non-normative. Nothing major. Open issues but no
open PRs. Discussion around those open issues. Discussing CBOR encoding
restrictions such as forbidding indeterminate lengths, max depth,
preferred encoding.

• Beltram: To give the implementers point of view, adding new values
  to, for instance, the Rust Crate and enforce it took about a year to
  add. Things like indeterminate length will be tricky.

• Mike Jones: Trying to limit the time claims to integer values fly in
  the face of how time values have generally be used. Having
  fractional seconds is perfectly fine

  • Rohan: there is text in the security considerations that says
    you can potentially use floating point values if it is important
    to your deployment.
  • Mike: seems orthoganal
  • Rohan: How do you feel about these 4 proposals?
  • They're fine and any otherissues we can discuss offline

• Carsten Bormann: We get to decide about these encoding restrictions
  and we need to be very thoughtful about what we restrict and allow

Rohan: Not hearing many objections around what was proposed moving
forward.

Status updates. No major normative changes needed only section missing
is the decoy digest section. We already have some implementations! There
are 1.5 Rust implementations alongside JS and Python implementations. If
you have your own implementation or would like to write one, please
reach out to Rohan.

Draft-ietf-spice-vdcarchs/wallet//g

Discussion led by Leif Johansson. We're re-writing a draft of this that
was originally written from IETF 124. We'd like reviewer sfor this new
draft.

Adjourn.