2024 11 13 Meeting Notes - WICG/digital-credentials GitHub Wiki

2024-11-13 (B Call)

Organizer: Tim Cappalli

Scribe: Matt Miller

Agenda

Attendees

Please add your name and affiliation

  • Tim Cappalli (Okta)

Notes

Administrivia

  • Canceling 11/27 meeting

Intros from any new folks?

  • None

Ecosystem Updates

  • Fed ID WG charter updates
    • Tim: In the process of being resolved. Small tweaks will be made to charter text
    • Wendy: Council has been formed, in the hands of the council to make a determination
    • Lee: Does anyone have an idea of expected timeline? Felt like things were coming to a close, is this an accurate interpretation? Weeks away?
    • Wendy: Team report goes to council, council is the deciding body. Simone said within 45 days council will need to meet, write Report of Decision, return to WG
    • Lee: Is there anything we can do about questions, etc…?
    • Wendy: We can respond to those questions if they come up, Simone will let us know
    • Marcos: What's the usual timeframe for the whole process?
    • Wendy: This is a newer process, an attempt to make quicker decisions in response to objections like this
    • Marcos: But no other group has used this process before?
    • Wendy: PATWG was just announced after going through a similar process
    • Tim: Under three months for PATWG?
    • NickD: Privacy group went through this, took eight months for report to get drafted before it was then handed to council
    • Rick: If we work under the assumption it'll take 6mo - 1yr to accomplish, that's unacceptable.
  • Incubation
    • SamG: Chrome, cross-device implementation was merged, just waiting for binaries to release to the public. Estimating December for the general public to flip flags and use this with a vanilla phone. Origin trials are already in progress. Early Q1CY25. Started to build a prototype for issuance, demonstrated at IIW October '24. Not married to API implementation at the moment, feedback welcomed. Not sure how long it'll take to merge in to Chrome Canary. Possible to get merged into Canary before EOY CY24.
    • Lee: Updating test sites to match the latest OID4VP spec. Going to put a new wallet app up on GitHub, simpler. Just implements OID4VP and OID4VCI, something as close to what we're likely to ship pending any final changes to OID4VP.
    • Matt: Is the query language going to be an option or The Way to define presentation requests?
    • Lee: Group seems to prefer to embrace QL, but legacy requires some backwards compat.
  • OpenID DCP working group
    • MikeJ: OID4VP public review draft, 45 days. Vote goes on for two weeks, ends just before Christmas. Still some debate on OID4VCI process(?), trying to arrange a call to iron things out. Start public review period of last implementers draft. None of these are final, final drafts expected sometime in March. Want to get feedback on query language from implementations while it can still be changed.

Discussion

Issue: Top level request object structure should be fully defined by protocol identifier #185

  • Tim: Signed request looks very different from unsigned request. From DX perspective this looks awkward. Should these requests be different identifiers?
  • Marcos: This seems outside the scope of the WICG
  • Lee: In support of having an identifier. Requests are different enough
  • Brian: This discussion should be handled over in OIDF
  • Tim: Registry of protocol IDs is in this spec, so that part is relevant here
  • Lee: Could still write the sentence that contents of data will be defined in OID4VP
  • Brian: Generally speaking, protocol identifier ID's the protocol. Is likely to cause more harm and confusion breaking up protocol identifiers
  • Sam: Registry lives in this spec, but algorithm lives in OID4VP spec. Therefore this seems like an OID4VP concern. If they feel like they'd benefit from a separate string for protocols then this spec could incorporate that.But adding something extra here but OID4VP didn't then it wouldn't have any effect.
  • Tim: The ergonomics of this API are for the consumers of this API, not for OID4VP. Registry is providing a map only in the context of the DC API. Identifier is paired with a link to the OID4VP spec that describes the protocol
  • Sam: If OID4VP group would benefit from the separation then we could introduce it
  • Tim: There's a benefit to developers to communicate the different protocols
  • Marcos: IANA ensures that certain accommodations are made for a protocol to be included. Having a top-level protocol identifier that does these kinds of changes we'd reject adding to the registry. "Hey, you shouldn't bechanging these structures." So we could e.g. provide guidance to OID4VP if they attempt to define different request structures under the same identifier.
  • Brian: Media types registry doesn't go out and find where media types need to be registered, then assign them an identifier. I assumed that this model would be similar. It doesn't have to be that way, but it's how these thingstypically work. Real guidance can be offered of what goes into the registry. Various ergonomics are different for different people, it's reasonable to think there'd be better ergonomics as separate identifiers; others wouldthink it reasonable to keep identifiers consistent. Would be super awkward to have a registry seek out and assign identifiers.
  • Matt: Having two protocols seemed like a slam dunk, but acknowledge prior art that it could have unintended consequences. Possible to pull this off without introducing new identifiers
  • Marcos: We own the registry and the rules about getting into it. If a protocol doesn't match the quality and privacy requirements then it wouldn't be included.
  • Tim: Question 1: Do we think this is a good idea? Introduce a new top-level value?
  • Brian: Doesn't want to add more "stuff."
  • Tim: A SIGNED/UNSIGNED enum? Registry inclusion could dictate specifying one of these values to be included
  • Brian: Better to engage the WG where these identifiers are being declared to consider assigning new identifiers.
  • Tim: Not disagreeing that it couldn't get solved at protocol level. Can we agree there's a need to make this request to OID4VP WG?
  • Marcos: Let's trial the registry and see how it goes. Learn by doing.
  • Sam: Just wanted to note that cost Marcos is paying is not the cost that Chrome is paying from architectural differences. Users aren't going to know the difference, but developers will pay the cost.
  • Matt: If developers can easily map from protocol identifier in DC API to appropriate protocol spec then there's a chance to push this off to the registry. Where would be responsible for maintaining these links for devs tofollow?
  • Tim: Web implementation helps shape platform APIs.
  • Lee: Less nice to introspect data structure to understand shape of data
  • Sam: Speaking personally, intuition is from experience with FedCM. From a DX perspective, we would send users to OID4VP, then over there define how to use the protocol from that spec. Could work the same here.
  • Tim: Timeline of when OAuth arrived on the scene to when FedCM dropped, may not be analogous to things now because VC protocols are being defined alongside transport APIs like DC API
  • Brian: Recognize there's different viewpoints on what's complicated or not. Would be great if this represented collaboration between DC API and protocol WGs
  • Lee: Not the hardest thing to solve, more implicit than explicit right now. Would be nicer to make things more explicit. "Presence of this field is how to parse it" makes things implicit.
  • Tim: Reiterating that this much conversation on this topic means we shouldn't punt.
  • Marcos: Would love to see collaboration in the community around this as protocols and DC API evolve together.

PR: Add additional use cases and examples to intro #186

  • Manu: One edtech group has done education credentials, diplomas, trainings, etc… No travel visas issues yet. Proof of employment…
  • Marcos: Do these work over the browser API?
  • Manu: Not yet
  • Tim: No binding between API and schema.
  • Marcos: Concern is that someone reads these use cases and none are actually supported yet. No concerns if these are future-looking concerns

Issue: write security considerations #184

  • Tim: On last call, it was said we don't need this because "it's being written with security in mind"?
  • Marcos: Security groups get annoyed with things like this being written in many places, would prefer that these efforts "bake it into your stack"
  • Tim: Equivalent, comparing to WebAuthn, would be the client validating various aspects of the response
  • Nick: Group has some assumptions in security model that should be clarified. No one can understand or evaluate the spec without these assumptions written down. If I just received this spec and the security considerations section consists of, "we answered some questions but didn't really think about it," why would I use this?
    • Manu: Effort is to wrap up community report, not draft entire security consideration atm. WG can draft that.
    • Tim: CGR will not be treated as an official document for citation. Will be clear that things will still need to get worked out.
    • Tim: Can we publish CGR1 as the security consideration section appears today? (General approval signaled by group)
    • Nick: Can take a look at text when it's ready
    • Tim: The text is ready now
    • Nick: Will reflect poorly on the WICG as-is
    • Manu: As an interim can we take what's in the formal objection and draft more considerations around those? It's not perfect but could be better?