2025 04 02 Meeting Notes - w3c-fedid/digital-credentials GitHub Wiki

2025-04-02 (B Call)

Organizer: Tim Cappalli

Scribe: Helen Qin

Agenda

Attendees

  • Tim Cappalli (Okta)
  • Brian Campbell (Ping)
  • Loffie Jordaan (AAMVA)
  • Matthew Miller (Cisco)
  • Rick Byers (Google Chrome) [first half only]
  • Helen Qin (Google Android)
  • Mohamed Amir Yosef (Google Chrome)
  • Simone Onofri (W3C)
  • Hiroyuki Sano (Sony)
  • Wendy Seltzer
  • Marcos Caceres (Apple)

Notes

PR & Issue Review

Go over FPWD Blockers
JSON Serialization https://github.com/WICG/digital-credentials/issues/125
Marcos: Not a blocker? Need additional changes.
Helen: useful for Hybrid. Can stay at a high level.
Marcos & Tim: the current PR might be enough. Double check later between the Marcos and Tim.

Issuance https://github.com/WICG/digital-credentials/issues/167

Marcos: Not a blocker? Need a second implementor

Lee: Openid4vci needs to reference is

Rick: second implementor is not a requirement for FPWD.

Sam: +1 not a requirement for a Working Draft. Is Safari not implementing yet due to sequencing or objection?

Marcos: sequencing and massaging.

Sam: does help with the issuance support in ARF to include in the WD

Marcos: Let me check and get back to you

Tim: would be great to have an answer by next Friday's F2F

Tim: Anything else needed other than final review Mohamed?

Mohamed: no

Registry: https://github.com/WICG/digital-credentials/issues/58

Tim: Let's go over the registry criteria together first.

Sam: requirement 3 / 4: are we talking about a WebIDL for an OpenID4VP request? Wouldn’t that prevent OpenID foundation from evolving their spec before being unblocked from this WebIDL update?

Marcos: no. It’s defined in their protocol.

Sam: So they have automacy to update this but wouldn’t they be stuck by browser updates to take in the new WebIDL

Marcos: Yes but that’s an implementation detail. We can update the wording to make it less scary. For some browsers e.g. Safari this has to be.

Sam: would be worth going through this with the protocol folks.

Matt: Question with item 2. Issue 211 adding oid4vp judging by this rule - stable url can be a draft. What happens when oid4vp transitions from draft 24 to 25.

Tim: the url has to be stable so the intention is that it should be a more stable implementor / editor draft. Shouldn’t be updated all the time. Should be a snapshot of the spec.

Marcos: in my mind it should be the opposite. It should be an accessible url that always points to the latest, non-breaking spec. Doesn’t need to directly land on the spec, can point to the latest compatible spec.

Lee: How are you gonna deal with minor versions? Would they need to make a new WebIDL and wait for browsers to update? How do they iterate on a working draft without having to be blocked by the browsers?

Marcos: works like html does which updates weekly.

Lee: but won’t be true for these specs right.

Lee: If we are defining registries at all, we should be opinionated. Should we add a line to say that we should be opinionated about adding a registry and ensuring that it doesn’t hurt or fragment the browser ecosystem.

Marcos: item 10 might satisfy

Lee: yeah as long as we have an item showing that intention

Tim: alternatively, should we revisit the decision and pick one presentation and one issuance protocol for the DC API. Then fragmentation concerns are completely resolved.

Sam: +1 should revisit.

Tim: don’t see additional value for having annex-C

Sam: Maybe it’s better to stricten the DC definition

Tim: DC isn’t equivalent to Digital government ids.

< People debating whether that’s a feature or an issue. >

Lee: What I want to prevent is fragmentation. I don’t want to have to tell RPs you have to implement protocol 1 on these browsers and protocol 2 on others. That compromises the value of internet standards if everyone is doing their own thing.

Matt: Do we foresee any issues with requiring an exchange protocol being freely available? Supports the requirement, but what would it mean for the registry if e.g. ISO MDOC issuance became more common?

Marcos: about fragmentation of different protocols, people can still generate different requests. For example on webkit we are not doing OpenID4VP and only mdoc (annex c) and that should be ok. You can’t force someone to use openid to use the DC api.

Tim: push back on the word “force”. But a spec can certainly only support one profile. E.g. Webauthn is the single passkey spec, and it always works.

Tim: oid4vp can do everything. Annex C can do a subset of oid4vp. Why would you want annex c?

Marcos: it’s not always good to be flexible.

Sam: difference between high level and low level apis.

Marcos: totally support including oid4vp in the registry

Tim: Another option is to just have 1 protocol for DC.

Matt: Wouldn't Annex C be left out since it’s not free?

Tim: There's multiple reasons based on the current criteria, not just being free

Tim: We'll continue discussing this at the F2F.