2025 01 08 Meeting Notes - WICG/digital-credentials GitHub Wiki

2025-01-08 (B Call)

Organizer: Tim Cappalli

Scribe: Heather

Agenda

  • Administrivia
    • Potential F2F meeting on April 11th (post-IIW), pending charter approval
  • Intros from any new folks?
  • Ecosystem updates
    • Fed ID WG charter updates
    • Incubation
    • OpenID DCP working group
  • PR & Issue Review
    • PR: Add initial intro text (#193)
    • Issuance (#167)
    • Add a way to check what protocols are supported #168
    • Visualize transaction data in confirmation dialog (#195)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Mike Jones (Self-Issued Consulting)
  • Heather Flanagan (Spherical Cow Consulting)
  • Rick Byers (Google Chrome)
  • Sam Goto (Google Chrome)
  • Matthew Miller (Self)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Rene Leveille (1Password)
  • Lee Campbell (Google Android)
  • Tobias Looker (MATTR)
  • Wendy Seltzer
  • Hiroyuki Sano (Sony)
  • Nick Doty (CDT)
  • Helen Qin (Google Android)
  • Dirk Balfanz (Google)

Notes

Administrivia

  • Tim: Potential F2F meeting on April 11th (post-IIW), pending charter approval. FedID WG and WebAuthn are meeting that day as well; expect to have an overlapping lunch. This wouldn’t be a formal overlapping set ofmeetings. We haven’t figured out which group will be in the morning, which will be in the afternoon. Expect this to be hosted at Microsoft or Google. Monday will be an OpenID meeting and (probably) a DCP meeting.
  • Tim: The next two meetings are “on”. Travel is picking up again so we may see them cancelled (e.g., during OSW)

Intros from any new folks?

  • no new people

Ecosystem updates

  • Tim: No Fed ID WG charter updates; still waiting to hear back from the council
  • Incubation
  • OpenID DCP working group
    • Tobias: The third OpenID4VP implementor draft has been approved and is in a public review period for VCI with members of the OIDF. A lot is going on in that group right now.
    • Tim: What about the HAIP for the digital credentials in the appendix?
    • Lee: OpenID4VP is a big spec with lots of optionality. But if you want to have interoperability, you have to pick some of the options. There is a High Assurance Interoperability Profile (HAIP) that attempts to make those choices for you. In the EU, the wallets and issuers will implement HAIP. Also, some US DMVs. Think about this as the spec you’ll implement. It has a lot of call-outs for the DC API as well as other things.
    • Tim: On the last call, there was a desire to make an even stronger statement about preferring the DC API.
    • Lee: Paolo will talk about this in the context of the ARF on the next A call.

PR & Issue Review

PR: Add initial intro text (#193)

  • Tim: Would like to close this today if possible. It has received a lot of comments in the last few days. Added two items to the goals.
  • Marcos: That’s something that comes with the implementation but there is nothing in the spec thmandates this. These are things that naturally occur.
  • Tim: Yes, this is in the goal section; it doesn’t need to be explicitly in the spec.
  • Marcos: Worried that people will ask “but how do you do that?” We all agree here and it shouldnbe an issue, but worried people will come back with requests for more explicit text in the spec.
  • Rick: That there is an API instead of custom schemes should answer that; it defines the format. BI’m not attached to the text.
  • Lee: It’s in the intro text; it is not normative spec language.
  • Marcos: Yes, but everything gets taken out of context. Will re-read and comment. Probably will fine.
  • Tim: There are also editorial changes. Sam, do you want to talk about the term?
  • Sam: Have been using the term “Digital Credentials” across the board, but there seems to be a pufor “verifiable digital credentials.” Fine either way, but we should pick one.
  • Marcos: The decision has implications. Either we link to the definition in the model, or we stito our guns and just say “digital credentials”.
  • Sam: In the spec, we’ve defined what a digital credential is, but we haven’t defined whatverifiable digital credential is. We can either rename our definition OR we can use the term used the spec today.
  • Tobias: As an umbrella term, digital credentials is better, because verifiable digital credentiasounds too much like verifiable credentials and just think this is about W3C VCs.
  • Marcos: I agree. We have the formal definition for digital credentials and it does cover tcryptographic component, so that should take care of some concerns.
  • Tim: In my circles, VDCs have landed well. NIST has chosen that as well. Would like to align wiNIST.
  • Marcos: If we want to align with NIST, we should point to their definition.
  • Tim: We may be overindexing on this.
  • Marcos: But it’s already coming up and people are asking questions. Let’s stick with DigitCredential for now and file a bug to align with NIST because we have competing definitions.
  • Tim: I think the path to least resistance is to just align with NIST.
  • Marcos: is the NIST document a standard? It looks like it might just be a blog.
  • Tim: There is no normative reference; no one owns these terms.
  • Marcos: Still want to file a bug about the NIST term and make changes in the spec to keep wiDigital Credential for now. We can align when NIST publishes something more authoritative.
  • Tim: They have commented on the PR.
  • Marcos: Then let’s fix our definition; it would be great if they could propose text.
  • Sam: NIST is one of the many places where we discuss these things, but what about the OpenID4VP ISO discussions?
  • Lee: Normally we talk about the DC API. That’s referenced in the specs. We don’t call if the VAPI.
  • Tim: There is no proposal to change the API name.
  • Lee: Then I prefer not to change the name to keep it internally consistent, though I see where trequest is coming from.
  • Mike: One of the precedents is that the working group is the Digital Credentials Protocols workigroup, and things are moving in that direction. After the big naming conflict between the VC aOAuth working groups about media types, that was changed to just “dc” for digital credentials.
  • Lee: DCQL is also digital credentials.
  • Ted: I’m concerned about the attitude from folks about sticking to their guns to create a generterm that will encompass everything. It won’t encompass VC as defined by the W3C VC working grouIt’s unfriendly to create a wrap around term that doesn’t actually include all the stuff itwrapping around. VCs as defined as the W3C are digital and always involve a machine language of sokind. The things we’re talking about with the DC API are not going to be compatible with the W3C model.
  • Tim: Pulling back slightly - the goal is to encompass everything and get away from the VC terbecause while technically no one owns it, there is still a perception that the term is owned by tW3C VC WG. Consensus so far seems to be to use digital credentials, so will make that change in tPR.

Issuance (#167)

  • Tim: Want to ask Sam: are you at a point to write spec text?
  • Sam: we were talking about that this morning! Yes, we have a prototype in Chromium that people are playing with and completes and end-to-end flow, but it increases the scope for the work of this group.
  • Marcos: The way we did the previous work to prototype, build an explainer, and then share around before spec text seems like a good idea. We aren’t quite there yet, but it’s a good model to follow. Let’s do that.
  • Tim: We’re not defining a new API, we’re just adding a create method.
  • Sam: In agreement with Marcos. We’ve been experimenting with a process in the FedID CG/WG to transition from prototypes to text, modeled off of TC39. Building off that, we’d say this is at Stage 1
  • Lee: It’s becoming more pressing because the OpenID4VCI and VP specs are on the same timeline. While OpenID4VP does reference the DC API, we can’t reference the DC API in the VCI spec yet because we don’t havissuance information yet. The pilots going in the EU are still using custom URIs for issuance. The pressure to have something to report to is significant.
  • Tim: We know what this is going to look like, a protocol field and a data field, and it will defer everything else to the protocol.
  • Sam: There were a few API questions we were asking as we built the prototype. Example: When you call the create, do you also have to pass an array of requests and each wallet understand different protocols, or shoulthe verifier know what protocol the wallet will be speaking?
  • Tim: Can you write those questions and ideas down in a lightweight explainer? Documenting what you did modeled off of GET?
  • Lee: We can do that.
  • Sam: If Tim would open the issue, the Chrome team can get the initial explainer started.
  • Lee: It’s like a GET, but I think it needs an array.
  • Tim: Can you have something by Monday so we can discuss on the next call?
  • Lee: Will aim for that.
  • Marcos: Let’s avoid having experimental ideas in the spec. We’ve avoided that so far.
  • Sam: Do you consider issuance at the same level of importance as presentation?
  • Marcos: That’s a product question; can’t answer that.
  • Rick: There might be a mismatch between the urgency Lee is feeling and Marcos’ point about implementer interest. If we don’t have a second implementer for issuance, what’s our path to resolve that? Will we need separate spec?
  • Tobias: Is there a difference between near-term interest in implementing it and general interest in a solution?
  • Marcos: Given it’s built on credentials already, and it looks so much like GET, we could start with that as a general path forward. If you don’t support GET, it returns null (or something like that). The actuacreation aspects are up to the protocol, so it would have to be generic to support multiple protocols anyway. I don’t see this as a blocker.
  • Lee: We’ll write the explainer to discuss on Monday.
  • Rick: Shall we write it as a PR for the existing explainer?
  • Marcos: That’s fine. But explainers get out of date quickly, so there may be other stuff in there that isn’t right anymore. Otherwise do it in the issue.
  • Tim: do whatever makes sense, we can always move it.
  • Lee: We’ll put it in the issue as a place to start the debate. We can turn it into a PR later if desired.
  • Tim: if you have a strong opinion about whether this should be an array, please comment on the issue!
  • Nick (from chat) - we sometimes hear from issuers that they want to know/control/identify which wallet ... which seems different from the model of just `get()` where the wallet is hidden and all of the details arpushed into the protocol
  • Tobias: from a OpenID4VCI perspective, there is a surface for the issuer to have an enforcement policy. That doesn’t effect something from a create perspective.
  • Lee: We take the credential and say to the wallet “can you handle this credential offer?” and the platform renders a wallet selector. The user picks one and the wallet finishes the flow. We assume the wallet is actinin good faith. If the wallet lies, it would fail to actually issue when it gets to VCI. So, same architecture as GET but returning potential wallets rather than credentials.
  • Nick: Is it just going to check later when it gets a signed key and it fails? That seems like a worse situation than the GET selector.
  • Lee: the hard fail point is the wallet attestation point. In the credential offer you don’t want wallets that will fail to offer themselves up, which means they need enough information to know if they can service threquest.
  • Tobias: Credential offer conveying what wallet can obtain the offer and provide themselves to the selector is a GET. Having this API sufficiently defined allows us to them figure out how to extend the credential offedata structure fail early so wallets won’t offer themselves up to the selector if it’s destined to fail. Add a way to check what protocols are supported #168
  • Tim: we have been going back and forth on this one. When last we left our humble explorers, there was concern that if one implementation always returns true, and one returns true more explicitly in certain casesfeature detection doesn’t offer much value.
  • Sam: iirc, Chrome would always return true, Safari would return false sometimes, so the question is: if that’s useful for websites? There are three valid options: agree that it’s not necessary and it can be an erroror introduce a web platform API that would let implementors test, or allow implementors to check the strings.
  • Tim: That’s what this issue was trying to capture - the method to do the detection. but there are concerns that if Chrome always says yes, then you’re really just checking to see if this is working for Safari.
  • Tobias: You’re trying to determine where you have to do something user-agent specific. Browser detection is not a great path to follow; we should focus on feature detection.
  • Rick: We don’t like three, we probably have to do one and define an error code, so then the question is: are there any customers who finds an error code insufficient and instead wants option 2 but know it won’t woron Android? What is the developer need?
  • Marcos: the justification in the first place was developer need. In order to find out whether a feature is supported, the user has to click on something, meaning the user is presented something and then it breaks, anthat’s unfortunate.
  • Lee: there is never a case where you wouldn’t have to write fall back code.
  • Marcos: That negates the need from having the registry in our spec.
  • Lee: Even if they are supported, there is no guarantee there is a wallet that can act on them.
  • Marcos: But that’s not the question being asked of the API. Does the browser API know how to cope with another API. That’s all that this should be answering.
  • Lee: If Chrome is always returning true, you’ll still have to deal with all the errors coming out of it.
  • Marcos: then the question needs to change with what this is answering.
  • Tobias: One example I’ve encountered - we have model protocols and if you’re an RP that wants to do a request that spans all of those protocols and put a multi-protocol request together, you’re going to have trebuild the request until you get the complete list. If you can put the request together that doesn’t require the users to keep interacting, that’s a win.
  • Will pick this up again on the next call
    • Visualize transaction data in confirmation dialog (#195)
  • AOB