Skip to content

2025 01 22 Meeting Notes

Jump to bottom
Tim Cappalli edited this page Jan 24, 2025 · 1 revision

2025-01-22 (B Call)

Organizer: Tim Cappalli

Scribe: Matt Miller

Agenda

  • Administrivia
    • Potential F2F meeting on April 11th (post-IIW), pending charter approval
    • Feb 5, 10, 24 canceled
  • Intros from any new folks?
  • Ecosystem updates
    • Fed ID WG charter updates
    • Incubation
    • OpenID DCP working group
  • Community Group Report
  • PR & Issue Review
    • Add getClientCapabilities method for feature detection (#200)
      • Add a way to check what protocols are supported (#168)
    • Issuance (#167)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Matthew Miller (Self)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Loffie Jordaan (AAMVA)
  • David Waite (Ping Identity)
  • Marcos Caceres (Apple)
  • Wendy Seltzer
  • Hiroyuki Sano (Sony)

Notes

Administrivia

  • No updates on charter
  • F2F still tentatively planned for April 11

Intros

  • No intros

Ecosystem updates

  • Incubation
    • Rene: Demonstrating presentation from 1Password wallet
      • How presenting an mdoc from 1Password could look on Android. Implementation will take a while to get to GA because of all the moving parts.
  • DCP WG Protocol Identifier Discussion
    • https://github.com/openid/OpenID4VP/pull/381
    • Consensus not yet reached after call this week
    • Minimum bar for protocol identifier is to identify a "subtype" of credential
    • Brian: We did not necessarily have consensus within this group. URNs with versions can confuse others in the future, causing compatibility issues.
      • Tim: Others expressed idea that consensus had been reached here
      • Brian: Discussing URNs here is not necessarily the best use of our time, and we shouldn't try to incorporate things that we'll regret later
      • Tim: Let's discuss and try to get to consensus?
      • Marcos: Is this for OID4VP
        • Tim: This is for any protocol
      • name:subtype:subversion
    • Four questions about shape of URN:
      • 1. Should version number be in the protocol identifier? (y/n)
      • 2. What specificity should the version number be? (major&minor Vs. just major)
      • 3. Should the request type (e.g., signed or unsigned) be included in the protocol identifier? (y/n)
      • 4. What format should the protocol identifier be? (URN, unstructured string, etc.)
    • Lee: Ideally you can read the URN and understand how to parse the request. Otherwise, you have to probe the protocol, and try to discern what version is being used. Two options: 1) opaque protocol strings, or 2) make URNs more structured. Option 2 makes protocols think about more structured identifiers.
    • Marcos: Protocol identifier shape should be guidance
    • Tim: This was a minimum set of requirements, with a recommendation that it be an URN
    • Marcos: We shouldn't recommend it be an URN
    • Lee: So maybe we put it in guidance that protocols should pick a unique identifier to indicate request version?
    • Tim: Is that different from the three core areas picked to identify the version of the request protocol?
    • Brian: We shouldn't offer guidance that has long-term negative repercussions. It's harder to convey in written text how rigid protocol identifiers have downsides for everyone to understand and not make the same mistakes.
    • Lee: What if guidance suggested that protocol identifiers SHOULD indicate an incompatible breaking version change?
    • Tim: Conversation started here in https://github.com/openid/OpenID4VP/issues/326
    • Matt: In a world where there are no structured protocol identifiers, where does that push the complexity, up or down the stack? Everyone picking random strings, etc. Could affect adoption if it bubbles up.
    • Marcos: That's what we do for other things in the platform. Hope is that these things don't change very often and can be identified by strings
    • Tim: Do we want to keep or close https://github.com/openid/OpenID4VP/issues/326? The problem statement remains the same, and there are two proposals on the table. Do we add an additional proposal?
    • Marcos: Added a comment to this issue
    • Tim: So what are the next steps?
    • Tim: Can we say we have consensus that we should NOT mandate that protocol identifiers are URNs?
      • Consensus has been reached, DC API will NOT mandate that protocol identifiers are URNs
    • Tim: Do we want to define guidance on protocol identifier structure as a requirement to be included in the registry?
    • Lee: All the things you expect a wallet to know how to function at all, that set of parameters needs a unique label. Any change to the set needs a new identifier
    • Brian: Registries contain strings, numbers, URNs, etc… with information about that document (or a link to the document where the protocol identifier is defined)
    • Tim: So how would you link to an updated entry? Seems to suggest importance of a version identifier
    • Rene: As a wallet, it is very difficult to keep track of the evolution of things. Versioning a spec or versioning a string requires looking up the latest version of that protocol. Reducing a certain level of indirection is desirable for easing adoption of new/updated protocols and document formats.
    • Brian: Let's not encourage people to put "v1.0" in protocol identifiers
    • Tim: Do we agree collectively that the top level structure mandates cutting a new protocol version string when any parameter changes?
    • David: We can give guidance on what the protocol identifier is used for. It becomes the responsibility of those who define the protocol to make sure that breaking changes are communicated as a new version. Different groups may have different ways to indicate different versions. How compatibility is maintained is the responsibility of the body owning the protocol.
    • Rene: Functionally, as a wallet, we're going to have to do branching logic. If new fields get added and the ID doesn't change it will break wallets. What use cases are there that would necessitate making this guidance a SHOULD instead of a MUST?
    • Tim: What is the point of having registry criteria if we can't MUST things like this?
      • Marcos: This is a bit of comparing apples to oranges. If a standards org wants to mint "mdoc" as the thing they should be comfortable to do so, so long as they've read the requirements and believe they can pull it off.
      • Tim: But what about malicious standards orgs that break the API but choose not to create a new protocol identifier?

PR & Issue Review

  • Add getClientCapabilities method for feature detection (#200)
    • Please review before next call
Clone this wiki locally