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

2025-01-27 (A Call)

Organizer: Tim Cappalli

Scribe: Nick Steele

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
    • Use a URN for protocol identifier instead of an unstructured string (#191)
    • Add getClientCapabilities method for feature detection (#200)
      • Add a way to check what protocols are supported (#168)
    • Issuance (#167)
    • multi-wallet requests (#201)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Nick Steele (he/him) (1Password)
  • Matthew Miller (Cisco)
  • Lee Campbell (Google)
  • Simone Onofri (W3C)
  • Chris Needham (BBC)
  • Loffie Jordaan (AAMVA)
  • Benjamin VanderSloot (Mozilla)
  • Rene Leveille (he/him) (1Password)
  • Nick Doty (CDT)
  • Helen Qin (Google)
  • Hicham Lozi (Apple)

Notes

Administrivia

  • Face to Face planned for April 11th, the Friday after IIW in Mountain View, California

Intros

  • No intros

Ecosystem & Updates

  • Simone to give update on the new charter

    • Email went out to the advisory council regarding chartership
    • In a waiting period

  • Tim: Checked with Paolo and OID4VP on the need for read out from the group

    • Would like to mint a CGR as a placeholder around May, but not needed before then
    • Simone: also chatted with Paolo & office, mentioned that we’ll inform them when presentation and issuance are more mature.

PR & Issue Review

191 : Use a URN for protocol identifier instead of an unstructured string

  • MattM: Already there is dependence on closed specs, how do we deal with that?
  • Tim: This is a bit of a parallel issue, should be a separate issue
  • Tim: Does anyone think Lee’s proposed text/example is sufficient?
  • MattM: Framing should be for those writing the protocols over anyone else.
  • Tim to note alignment and proceed to PR
  • MattM: In the context here, would an implementation author know to update?
  • Lee: If wallets on a specific version need to update, you need a new name
  • Lee: I don’t think the audience for this is particularly big, and currently there’s really only OID4VC
  • Considering this issue logically closed

200: Add `getClientCapabilities` method for feature detection

  • Tim: We should convey some set of capabilities for RPs to detect features
  • MattM: In the discussion, there was some focus on punishing users around the position of their walletverifier. It could be nice for UX/UI presentation purposes. Can be used more of a carrot than a stick, toguide users in a given direction.
  • Nick Doty: I had concerns around this for the reason that developers might use this to add friction inpresenting credentials.
  • Rene Leveille: I don’t think we can expect websites and developersto use all the methods at their disposal immediately out of the gate. The alternative is that RPs might useUser Agent sniffing, which happened in the case of WebAuthn. We can also help provide guidance toimplementers about how to use these features.
  • Nick Doty: One way to address the privacy concern when they have APIs like this, is to not provide fulldetail or enumeration, just provide the information requested by the RP.
  • MattM: We explored this in WebAuthn. Mozilla wanted getClientCapabilities to not send some signals in theservice of user privacy, so we intentionally wrote into the specification that clients may choose to omitcertain capabilities.
  • Discussion around the goals of what getClientCapabilities is providing, and how it can be presented in adynamic privacy-preserving manner.
  • Benjamin Vandersloot: It would be really nice if it was restricted around clients. I think this is mostuseful if we don’t have a carve-out for a privacy preserving version of this feature.
  • MattM: We should aim to help developers build for the 80% of people that will use this in the future. Weshould build for the majority first and then focus on the 20% after a first round of big impact.
  • BVS: It’s great to get 80% of people on board, but if the outcome is it only works on one engine, thenthat’s counterproductive. I do worry about developer experience but don’t want different flavors ofimplementation here.
  • Discussion around how to provide capability flows in a privacy preserving manner that doesn’t “blackhole” users, such as leading them down a UX pathway that will eventually fail.
  • Tim: This proposal seems to be contentious, will withdraw
  • BVS: still prefer this overall pattern over user agent sniffing resulting in static lists
  • There also seems to be a request from the group to get more of a developer perspective on this, especially from one(s) that would like to have this feature.