2025 02 19 Meeting Notes - WICG/digital-credentials GitHub Wiki

2025-02-19 (B Call)

Organizer: Tim Cappalli

Scribe: Heather Flanagan

Agenda

  • Administrivia
    • Update on Fed ID WG recharter formal objection
    • F2F meeting on April 11th (post-IIW)
    • Feb 24, March 5 canceled
    • DST: Keep current time or shift? (poll)
  • Intros from any new folks?
  • Ecosystem updates (capped to 5 minutes)
    • Fed ID WG charter updates
    • Incubation
    • OpenID DCP working group
  • Transition to WG
  • PR & Issue Review
    • What are the protocol identifier naming rules? Use a URN for protocol identifier instead of an unstructured string (#191)
    • Older Issues
      • Managing request format extensibility without sacrificing security (#102)
      • Requests' size should be checked before transient activation (#202)
      • Handling ongoing operations / subsequent call to get() (#159)
      • Handling various origin types (#160) - Marcos?
    • multi-wallet requests (#201)
    • Issuance (#167)
  • AOB

Attendees

  • Tim Cappalli (Okta)
  • Heather Flanagan (Spherical Cow Consulting)
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Marcos Caceres (Apple)
  • Loffie Jordaan (AAMVA)
  • Wendy Seltzer
  • Hiroyuki Sano (Sony)
  • Matthew Miller
  • Simone Onofri (W3C)
  • Lee Cambell (Google Android)
  • Mike Jones (Self-Issued Consulting)
  • Helen Qin (Google Android)
  • Brian Campbell (Ping Identity)
  • Dirk Balfanz (Google)
  • David Waite (Ping Identity)
  • Rick Byers (Google Chrome)
  • Rene Leveille
  • Isaiah Inuwa
  • Matthew Miller

Notes

Intros from any new folks?

  • n/a

Administrivia

Fed ID WG charter updates

  • Tim: let’s use the April 11 date for our kickoff meeting and work around that for scheduling/planning
  • Marcos: Date seems fine. What would the agenda be like, esp. if we’re going to meet for only half a day?
  • Tim: The DCP and WebAuthn groups are also meeting that day. We can try to get creative with schedules, but it will be difficult.
  • Matt: For the FedID CG/WG calendar, they often seem to have joint meetings. What would we be part of?
  • Tim: We’re not sure yet. DC API could be part of its own meeting series, part of the WG calls; all of that is still TBD. The question is right now are we in a good place to move this in the next six weeks.
  • Wendy: reminding anyone interested in this work, they should join the FedID WG. We do a lot of work as CG and WG, but ultimately for the draft coming over, it’s the WG that would be agreeing to take it in.
  • Brian: Participation in the WG requires a W3C membership?
  • Wendy: That or an application to be an Invited Expert, https://www.w3.org/invited-experts/#principles
  • Marcos: Is there an option to have a liaison agreement?
  • Simone: Yes, we have an agreement with the OpenID Foundation; ask Gale Hodges, ED of OIDF, about that.
  • Tim: reminder that everything that happens in the group is public; the only thing you cannot do is join the calls (unless explicitly invited by the chairs; not something the chairs should abuse). Meeting notes, issues, etc, are open.
  • Tim: With no objection, we’ll work with the April 11 date in mind.

Incubation

  • skipping for now

OpenID DCP working group

  • skipping for now

Transition to WG

  • see notes above

PR & Issue Review

What are the protocol identifier naming rules? Use a URN for protocol identifier instead of an unstructured string (#191)

  • Marcos: has implemented the strings as an enum value. Enums are, in theory, simple strings, but how they are implemented in browsers follows specific rules and limitations. JavaScript can only support dashes (for example).
  • Brian: from general experience with this kind of construct where some string identifier is used in a protocol, it will be implemented in a variety of ways on different platforms. Bringing in the constraints of web IDLs seems overly restrictive, particularly because we changed the identifiers in OpenID4VP in ways that might not fit in the construct of these new constraints.
  • Marcos: the discussion was “do we impose some structure with URNs?” The restrictions that come in with web IDL puts those restrictions where they might need to be. So rather than weird schemes, it’s a very simple opaque string that you can only put dashes into.
  • Brian: Yes, but enum implies a fixed set of things, and I don’t think that’s in the spirit of a registry mapping.
  • Marcos: Yes. It is treated as a simple string in the spec, but browsers have implemented that as an enum.
  • Brian: My concern is that the other major browser here might not care about that at all and will pass it through to the next component that will treat it as a string. I’m trying to liaise here and suggest this might break a recent change made in OpenID4VP that was done to accommodate the prior ask here. We need to reconcile these two.
  • Marcos: Open to suggestions.
  • Tim: OpenID is using the URN which would be incompatible with this.
  • Marcos: if we’re going to use URNs like URLs, we need to decide how to avoid some people using URNs, others using strings, etc.
  • Tim: That was the point of defining what the structure would be, and there was opposition to that.
  • Marcos: I am opposed to using a URN when a simple string will do, but it’s for the group to decide.
  • Tim: It would require another change on the OpenID4VP side. Would it be as simple as replacing the colons with dashes and changing URNs?
  • Brian: Maybe. Will bring it back, but it’s frustrating to rehash this in that group. That group is already overloaded with a lot of other tasks. They are looking to cut to final output in the next few months, so we need to nail down any changes.
  • Lee: What’s the final action?
  • Tim: Take this back to OpenID4VP to see if they’ll make a change.
  • Lee: What is Marcos asking for?
  • Marcos: URL-safe characters that will comply with the TAG and webIRL specifications (i.e., all lower case and dashes)
  • Tim: If I open the PR tonight, can it get on the next OpenID4VP call?
  • Brian: Maybe? Try it.
  • Lee: That seems fine.
  • Tim: we don’t have to change what’s in the identifier, just change the colons and remove the URN; keeping the same general structure.

Older Issues

Managing request format extensibility without sacrificing security (#102) — seems stale. Can we close it?
  • Marcos: I think this can be closed
Requests' size should be checked before transient activation (#202) — do we still need to do this?
  • Marcos: Yes, still valid. The tests are getting tripped up.
Handling ongoing operations / subsequent call to get() (#159) —
  • Marcos: We definitely need to put this in the spec.
Handling various origin types (#160) — was this already covered under secure context?
  • Marcos: Need to check. There is some stuff that WebAuthn does that we might want to align with. There might be nothing to do. In WebKit, it does a lot of these checks fairly early.

New Issues

multi-wallet requests (#201)
  • Tim: Kristina opened this. She’s not here (it’s a B call) but we can discuss.
  • Lee: From an API point of view, it doesn’t matter — can you return two credentials, yes or no? The Android implementation has that limitation because it’s hard to do, but it’s not a limitation in the spec. In the OpenID4VP level, they do have this ability, so in theory we do have to support it. We just have to figure out the UX.
  • Marcos: Depends on the semantics for what’s in the request. If you have an OpenID request and you need two credentials, I’d expect them to be in two requests.
  • Lee: We might do this by restricting the request to one wallet. In the fullness of time, we might have to support two credentials, two wallets, but it’s really hard to figure out how to manage the UX consent. So probably not a v1.
  • Marcos: If you have mDoc/OpenID/mDoc, do you take the two request blogs and send them over in the list of requests?
  • Lee: If you have three requests, we send the whole thing to each wallet and the wallet decides what it can return. At that level, they are all ORs. There is no AND construct; that can only happen inside a protocol. It will be handled atomically by one wallet.
  • Tim: From the DC API layer, there is nothing preventing this from working?
  • Marcos: Yes, but there should be guidance there. If you have x/y/x, what do you do? Send both, send all, or something. We should offer guidance so developers know what to expect. It would be non-normative, but it should be there.
  • Tim: What kind of developers?
  • Marcos: Website developers and other standards organizations that may want to leverage the API.
  • Tim: to directly answer Kristina, it’s supported, it’s up to the platforms to make it work.
  • Brian: This API supports sending multiple requests, but the protocol for VP also allows for requesting multiple credentials in the context of a single request as well as returning them. Does that change the discussion?
  • Lee: We’re saying it’s OK. You can pass in the request for multiple credentials and the wallet can respond to that. That will work in this API; it’s not a spec problem.
Issuance (#167)
  • Question from Nick
  • Still on track for a PR soon?
  • Tim: The PR came in only a few hours before this call, so probably people haven’t had a chance to look at it. There is still an open question about pre-authorized code flow.
  • Lee: We do want to support that flow. We also want to support when the user is unauthenticated in that website and will do some authentication in the context of the wallet. We have to support both; the spec supports that; we just have to implement. For what comes back, may be just a status code and you may not know what exactly happens. The intent is that you go back to the website and there will be something to tell that site what happened. Because of the way credential issuing works, there may be a delay between the request and the return code on the order of a few minutes. (Lee will reply in the doc)
  • Rick: I did look at the PR. We need to figure out how to spec the return type. The PR returns a digital credential which may not be right. We probably want a status code. Do we define status code or is that protocol defined?
  • Lee: The status codes should be protocol-specific. This might come down to the credential manager below us. For WebAuthn, it’s a public key credential return type GET. If we made a different type, it would have different parameters.
  • Marcos: Yes, it’s the type and data, and it’s just an object.
  • Tim: please take a look at the PR by the next call so we can have a deeper discussion then.

AOB

  • Tim: there will be a few more of these meetings before the April 11 meeting. Our next call will be in the new, post-DST time. There is a poll out about whether to keep the standard time or roll it forward; three people said keep it.
  • Marcos: This time works for me. And when there’s a shift, it will go back two hours, which continues to work.
  • Tim: We’ll plan to keep it in the same time slots, but there will be new invites and will say “2025 DST.”
  • Marcos: Speaking as ex-chair of WICG, we can go through the process of publishing a report, but we don’t need to. We don’t have to, we can just publish a FPWD when the group spins up. The report might be make-work.
  • Tim: The only reason to push the end-of-WICG snapshot is if we get into the WG and we don’t get a stable reference in time.
  • Marcos: As long as someone is willing to do the work, we can have that snapshot, but in parallel we want to supercede that very quickly with the FPWD.
  • Lee: How long would it take to get the FPWD out?
  • Marcos: It should be quick.
  • Tim: My fear is that while it can happen quickly, there will be a lot of new people in the group that need to chime in.
  • Wendy: From the WG side, it will be helpful whether the CG publishes a report or not, for you to clearly identify the snapshot of what’s in there that they recommend be in the FPWD so there is as little work as possible to get that FPWD out the door.
  • Lee: In Europe, the ARF 1.5 got published. This says what the EU Wallets have to implement. It says they must implement DC API with OpenID4VP, which is good, but now people are asking for the spec and there isn’t one. The quicker we can have that reference, the better. And a WG link would be better.
  • Tim: It is on us to make this go fast. We need to tag blocking issues, we need a deck to bring everyone else up to speed.
  • Wendy: For people not engaged in the FedCM work, that FPWD has a list of open issues the group feels are critical to resolve before more stable drafts come out. If that’s something that people here think is valuable, it’s an option.
  • Brian: for some more unofficial liaising, next Tuesday they DCP group is having a hybrid meeting before OSW. Normal participation rules apply in terms of group membership, but it’s an option.
  • Lee: there’s also the ISO test event coming up later this month in Utrecht.
  • Marcos: would be helpful to have 6 weeks lead time before requesting travel.