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

2025-01-13 (A Call)

Organizer: Tim Cappalli

Scribe: Heather Flanagan, Rick or Matt

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
  • PR & Issue Review
    • Visualize transaction data in confirmation dialog (#195)
    • Issuance (#167)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Rick Byers (Google Chrome)
  • Benjamin VanderSloot (Mozilla)
  • Nick Doty (CDT)
  • Lee Campbell (Google Android)
  • Heather Flanagan (Spherical Cow Consulting)
  • Andrew Regenscheid (NIST)
  • Ryan Galluzzo (NIST, ACD)
  • Loffie Jordaan (AAMVA)
  • Wendy Seltzer
  • David Waite (Ping Identity)
  • Madhu Goundla (Oneproof)
  • Mohamed Amir Yosef (Google Chrome)
  • Hicham Lozi (Apple)
  • René Léveillé (1Password)

Notes

Administrivia

  • Tim: plan for a f2f on the Friday post IIW, pending charter approval. Still, if you’re planning your travel, keep that in mind. Also, note meeting cancellations in February.

Intros from any new folks?

  • No intros

Ecosystem updates

  • Tim: No charter updates, no incubation updates, no DCP WG updates.
  • Paolo: In the context of the ARF, we have a list of 21 topics to discuss. We are publishing a discussion document on GitHub. This week we’re going to discuss the issuance topic. Please contribute to the doc so we can share the basic principles and requirements with the entire community.
  • Rick: Doc makes sense; people within Google have reviewed it. Would like to understand some areas a bit more clearly:
    • Consent vs Permission — the doc uses "consent" language. Google thinks more about permission. Are the interstitials that browsers are offering something they should avoid?
      • Paolo: That’s specifically about the user's access to the information in their wallet when a request comes in. That should be managed by the wallet, not the browser.
    • Trustworthiness of the RP — The nuance is tricky. There is text about how browsers "shall" protect users from untrusted verifiers, but there is also text about browsers not maintaining a list of trustworthy verifiers. Would like clarity here. Also, is it right that this is a “SHALL”, or should it be a “MAY”?
      • Paolo: We don’t want to have lists in the browser; that’s not their responsibility. The trustworthiness is about an authenticated RP. There may be a discussion about the origin as well. Also, this isn’t normative language.
      • Nick: Concerned about this. If we’re going to say consent is going to happen at the wallet level and not the browser level, that’s confusing because the wallet won’t know any of the surrounding context. They won’t have info from the site nor info about what the user was doing. If we want consent to be on the wallet side, we have to talk about all the information we’ll need to pass to the wallet so consent can be informed.
      • Rick: Agree at a high level. What’s necessary for informed consent? Probably need to pass two different origins to the wallet; there are cases where an iFrame will be involved. The user might want to reason differently about the top-level page and the iFrame (e.g., if something has been subcontracted out to a third party).
      • Paolo: Definitely the context is needed, but we expect something like “this RP is asking for this attestation and it is contacting you from this origin; do you consent or not?”
      • Nick: Being informed consent is more than who is asking and what they’re asking for. There’s also why they are asking.
      • Rick: A lot of that is in OpenID4VP already.
      • Paolo: The intended use will be in the registration certificates. The RP can only ask what will be in their registration certificate.
      • Ben: To Nick’s point, getting the context is there. There is some shared responsibility required. There will be stuff that the wallet can’t do (and the browser can). So maybe we need to think about the definition of consent here in this context. Another point, we want to clarify the point about “browsers shall not verify” and how that interacts with ONLY allowing EUDI requests against a list of RPs. Would blocking all other requests be against the spirit of that?
      • Rick: We had a similar question. We interpret these as requirements for the DC API when used in the context of EUDI, not requirements generally.
      • Paolo: Yes, this is specific to EUDI.
      • Ben: Want to make clear that anything outside EUDI is out of scope.
      • Lee: Most of the issues we’re looking at fall under what authority the requests are being made. The wallet is the only thing that can interpret and display this, as well as getting consent. It also is the only thing that can take on the liability of collecting that consent.
      • Ryan: Agree we need to look at this from a complete transactional view. The more we try to pack into what the browser has to do, the more we’re going to create choppy user experiences. The wallet is well positioned and the RP has a responsibility before the request is put in place. If there’s missing context, we need to understand what that is.
    • Suggest a fourth advantage — we have also talked about user transparency of control. Is that worth considering including as a benefit, or is it too specific to the web ecosystem as opposed to the wallet ecosystem?
      • Paolo: I see the wallet ecosystem as on top of the existing web ecosystem. If we’re talking about a remote flow, we’re always going to interact with the browser or an app. The users will always start at the web/app ecosystem before they get to the wallet. If you have a malicious website, it shouldn’t even get to the user yet nor call the wallet.
      • Rick: I would then interpret it as our bug that custom schemes allow websites to communicate with wallets. We can’t fix it (yet) due to compatibility issues.
      • Paolo: We need to benefit from protections already in place.

PR & Issue Review

Visualize transaction data in confirmation dialog (#195)

  • Tim: Someone asking about selection screen for payments, which is not going to be defined by the API. Lee responded, I think we should close based on out-of-scope. Any concerns with closing it?
  • None
  • Tim: Lee do you want to respond saying how to get in touch with Android, then close?
  • Lee: Yes, will do

Issuance (#167)

  • "Why" is the same as presentation: offer something better than custom schemes
  • The time is now to include issuance in DC API, or else custom schemes will get baked into other regulations for issuance while DC API handles presentation
  • Same overall structure as `.get()` — a list of requests and data
  • Intention is that a single request represents issuance of a single credential — multiple requests represent the same credential in multiple formats
    • Ex: If "OIDVCIv2" comes out, issuer can include OIDVCIv1 + OIDVCIv2 issuances in a single call to `.create()`
  • Matt: What is the return value?
    • Lee: Probably something simple, "SUCCESS", some similar code, etc… Confirmation of accepted format can happen out of band as per whatever protocol is used by the wallet to receive the credential
  • Tim: Would members of the requests array be required to be unique?
    • Lee: `.create()` is a little harder to rationalize having duplicated requests, if not for different protocols
  • Mohamed: `.get()` and `.create()` may benefit from using "requests" and "request" specifically, since presentation is seeking multiple possible credentials vs issuance is seeking to issue a single credential
  • Paolo (in chat): +1 I do support the proposal, it definitely needs to include issuance
  • Tim: Next step is to move Lee's comment into a PR
  • Sam: Can we get some guidance from Safari that this is directionally correct?
    • Probably need to wait for Wednesday call
    • Some organizations see presentation as a higher priority than issuance right now as there are more opportunities to solve privacy-related issues with presentation
  • Ryan: What are we deprioritizing for issuance? How might it impact delivery of presentation support?
    • Tim: `.get()` is basically done
    • Sam: Is there anything else missing from `.create()`?
    • (From chat) Ryan: "That seems to make sense to me, there is also the difference between getting it working into the spec and then prioritizing implementation."
    • Ben: This is a good conversation. Good to emphasize a difference between spec work and prioritizing implementation
  • Matt: Is there work in OID4VCI that needs to get added like DC API has callouts in OID4VP?
    • Tim: The group is aware there's work that needs to get done. They would be willing to submit a PR as soon as it came out.
  • Heather: Has the community report been submitted?
    • Tim: Not yet
    • Heather: The report should get issued as delivery of it with a promise of "issuance soon to follow" was previously communicated.
    • Tim: We can revisit on the next call if it's still beneficial to publish a static snapshot
  • Ryan: Seems the current question is how to prioritize the community report vs issuance within this group
  • Unofficial poll: "Continue with issuance PR" -> 12 yes, 0 no.
    • Tim: Lee / Sam you are free to proceed putting up a PR
  • Tim: Should we still issue a community report?
    • Heather: We wanted something to point to. Community report is not a tracked document, no standing or merit, so what's the harm?
    • Sam: It was originally intended for OID4VP to have something stable to reference
    • We'll check during the B call this week