2025-03-10 (A Call)

Organizer: Tim Cappalli

Scribe: Nick Doty

Agenda

• Administrivia
  • F2F meeting on April 11th (post-IIW)
  • Reminder to join the Fed ID WG
• Intros from any new folks?
• Ecosystem updates
  • Fed ID WG charter updates
  • Incubation
  • OpenID DCP working group
• Transition to WG
  • FPWD label

    • Issuance (FPWD blockers)

    • Registry (FPWD blockers)

    • Security Considerations (WG discussion)

    • Privacy Considerations (WG discussion)

  • Intent to Migrate issue
  • Consensus call for transition of the work
• PR & Issue Review
  • Issuance (#204)
  • API requests should provide the site with what they need to explain why and how requested credential information will be used (#44)
• AOB

Attendees

• Tim Cappalli (Okta)
• Nick Doty (CDT)
• Heather Flanagan (Spherical Cow Consulting)
• Wendy Seltzer
• Rick Byers (Google Chrome)
• David Waite (Ping Identity)
• Mohamed Amir Yosef (Google Chrome)
• Hiroyuki Sano (Sony)
• Rene Leveille (1Password)
• Nick Steele (1Password)
• Matthew Miller (Duo Cisco)
• Helen Qin (Google Android)

Notes

Intros from any new folks?

• n/a

Administrivia

• last meeting of March. next meeting is IETF conflict. next call on 2 April. other collaboration welcome in Github and Slack.

Face to face confirmed for April 11th, time still to be determined.
Heather: attendance is physically constrained. Let Heather know if you’ll be there. Lots of groups all trying to meet at the same time.

RSVP by letting Heather know.

Transition to WG

Join the Fed ID WG if you haven’t already; can take some time especially in big companies. We hope this work will transition by this time next month.

Tim: Marcos created an issue (205) on moving this to the WG. Not a decision that has been made by the WG yet. https://github.com/WICG/digital-credentials/issues/205

Heather: to be discussed by the WG on March 25th call.

Tim: WICG also has to make that same decision to migrate. Can discuss on the issue that Marcos created; can do offline because not everyone can make our calls. Will ask people to react/comment on the issue. A good practice is to start labeling issues that are critical for First Public Working Draft. Heather/Wendy can list in the spec what things will need to still be addressed before CR. Helpful for us to start doing now in the CG.

Started an issue label as FPWD:

• issuance
• registry, might need start over on the PR, to include OpenID4VP and OpenID4VCI. registry criteria
• security considerations, those are currently placeholders just referencing external documents
• privacy considerations
• anything else top of mind?

Wendy: process-wise, issues that are open at the time of First Public Working Draft (FPWD), so that when people read the first public working draft, they know that these things are waiting resolution. not things to be closed before FPWD, just acknowledgements of what’s open.

Tim: maybe FPWD-blockers (issuance and registry) and then FPWD-notifications that are still being worked on. Tim will come up with additional labels to distinguish.

Nick: doesn’t need to block moving to the WG, but I think it would be problematic to publish a FPWD without security and privacy considerations, but a decision for the WG.

Tim: description might be out of date from explainer, include issuance for example.

Comfortable with migrating this work, modulo what we just discussed?
(some thumbs up)

Nick: if you need help with Invited Expert participation as non-members of W3C, reach out, or ask WG chairs Wendy and Heather.
Wendy: yes, please reach out, we welcome participation.

PR & Issue Review

204: https://github.com/WICG/digital-credentials/pull/204 for issuance

open question: support multiple issuance requests in one call? leaning towards one per protocol identifier.

Matthew: are there user personas that we are designing for? some people have a strong image in their head of particular use cases, like multiple issuance. where should we contribute to documenting the use cases?

Tim: keep similar to presentation, only support one of each type, but might still include a list of issuance requests because of different capabilities in the wallet.

Matthew: is there a design doc that explains that? Tim: look at the issue again.

Tim: any scenarios where you need more than one per protocol identifier?

Mohamed: want to issue residence card and driver’s license at the same time, after you log in to a government website.

Tim: but those aren’t different payloads per protocol identifier. and a payload for a protocol identifier could include data for multiple document format types.

Matthew: for future versions

Tim: one request per protocol identifier? like for different protocol versions?

Matthew: probably okay.

Nick: we should be clear that these multiple requests are interpreted as exclusive-or, that the UA/wallet should only accept a single credential.

Matthew: if it supports both document formats, does the wallet end up with two copies?

Tim: the only goal of the API is to match the request to the wallet picker.

Tim: wallet will probably have backchannel requests to confirm that it’s completed.

Tim: should there be an enum of codes that the API would send back to the site? probably, in the future?

Mohamed: failure code for if the site sends multiple issuance requests for the same protocol identifier.

Helen: fine to start with that. if there is a need we see in the future, could relax it. Coming back there should be only one response. If an issuer says it supports the credential in multiple formats, the wallets need to indicate which they support. does it require two requests of the same protocol for an issuer to offer the same document in two different document formats?

Tim: or could start with no restriction and add it later. have to think about what is more backwards compatible.

Helen: matcher could identify that a match succeeds, but then the wallet could receive multiple compatible requests. the wallet will get the whole array of requests, but also receive from the operating system which they matched on.

Mohamed: would the wallet appear multiple times in the selector? up to the wallet if they say they match twice.

Matthew: does the DC API affect this? can the API nudge to use of the newest protocol specified? the issuer calling the API could order them in the preferred order maybe?

Helen: +1 for supporting that kind of ordering. or the wallet can write its own matcher that decides its own preference.

Tim: hard for the web platform to guarantee, but we can clarify that it would be unpredictable for the user if you try to simultaneously issue multiple credentials.

Tim: I will summarize in the issuance issue.
[no objections, some thumbs up]

44: https://github.com/WICG/digital-credentials/issues/44

Nick:

• still getting discussed in different circles
• Sites will be asking for presentation of credentials, do we want the site to explain why they request it and what they want to do with the information?
• Experience from Web Platform, when there isn’t any structure, sites just do whatever they want to get the desired information
• We have the opportunity to try and make it more straightforward
• One option is to present it in web content directly
• Other option is Mike West’s purposeful permissions doc: enum with purpose and other basic info

Matt:

• Thinking about some conversations that have happened in WebAuthn, ex: localization for messages. Also concerns about freeform text.

Nick:

• common questions / considerations that have come up. Advantage of using web content, some people think it's clearer that the message is coming from the site. Very clear way.
• Enum could help with localization and deception concerns

Matt: web content isn’t a new spec right?

Nick: Page Embedded Policy Control (PEPC), browser would be in charge of ensuring the user saw it

Rick:

• Thanks Nick, good exploration.
• Share concerns around option 2. Limited in the ways that Chrome could show UI for things it may not be responsible for.
• Excited about PEPC style. Aims to enable permission prompts to be integrated with web content. Still needs to be proven out though.
• Start thinking about a transition from current approach to PEPC in the long term (different friction for traditional request vs PEPC request)

Nick:

• Lots of experience with JS approach, which has shown challenges
• Even bigger implications for this
• If we don’t have any other mitigations, let’s look at this

Rick:

• We’re all competing against custom schemes (more popular than DC API)
• Would love to hear from other browser vendors as well

Nick:

• If goal is less abuse, having JS API with no user information will be very similar to custom schemes
• Not sure how it is different

Rick:

• Key difference is it gives more opportunities to evolve into other experiences like PEPC
• Custom schemes lacks context and request transparency
• Thoughts from others re: PEPC or the general idea of connecting web content?

Matt:

• Like PEPC to help influence browser what to show
• Feels like a cool use case for PEPC (usage and user research)
• But how many people read what the browser shows them? Might not be a silver bullet, but we should try.

Nick:

• Just to be clear, don’t think it will solve everything, but will be a mitigation.
• Nick to open issues for the two proposals, with links, for potential further discussion.

Next two meetings in March canceled.

Fed ID WG to meet March 25th.

Issuance coming soon.