2024-12-02 (A Call)

Organizer: Tim Cappalli

Scribe: Helen

Agenda

• Administrivia
• Intros from any new folks?
• Ecosystem updates
  • Fed ID WG charter updates
  • Incubation
  • OpenID DCP working group
• PR & Issue Review
  • Add initial content to Security and Privacy Considerations sections (#189)
  • Pending closure issues:
    • Update every example to include mediation="required" (#177)
    • Add a way to check what protocols are supported (#168)
    • Presentation request format validation (#152)
    • define a well-known way for a verifier to indicate registration, validation, trustmark assurances or other necessary info (#136)
    • Digital credential API should support requests for directed identifiers (#126)
• AOB

Attendees

• Tim Cappalli, Okta
• Zacharias Törnblom (SUNET, SeamlessAccess)
• Wendy Seltzer
• Dirk Balfanz (Google)
• René Léveillé (1Password)
• Rick Byers (Google Chrome)
• Ryan Galluzzo (NIST)
• Benjamin VanderSloot (Mozilla)
• Ted Thibodeau (he/him) (OpenLink Software)
• Mike Jones (Self-Issued Consulting)
• Helen Qin (Google Android)
• Mohamed Amir Yosef (Google Chrome)
• Andrew Regenscheid (NIST)
• Lee Campbell (Google/Android)

Notes

Incubation update

• Chrome issuance in Canary starting 133.0.6866 behind a feature flag (web-identity-digital-credentials-creation)

PRs & Issues

Update every example to include mediation="required" (#177)

• Tim: Can close?
• Sam: Should be marked as "won't fix" once marcos’ PR gets merged.
• Rick: Our implementation does not match the spec. Will propose an edit.

Add a way to check what protocols are supported (#168)

• Tim: Double check can close.
• Sam: Chrome’s implementation will say yes to every protocol. Other browsers may not.
• Zacharias: We may not support all the wallets.
• Tim: Maybe a different issue?
• Rick: Expected to be handled well at the protocol level, e.g., OpenID4VP.
• Rick: Advance feature detection is out of scope.
• Zacharias: Makes sense but breaks the user experience.
• Rick: Agreed. But the alternative is a tricky privacy problem.
• Lee: We should capture this decision and rationale of privacy consideration somewhere.
• Sam: The current issue being discussed is about whether or not pass-through is allowed. Hence, can avoid the privacy issue. In certain browsers, a request will only allow certain protocols to pass through, instead of leaking wallet existence or identity. Therefore, highlighting that this current issue isn’t about privacy but rather about UX improvement.
• Rick: Is this a fundamental design disagreement that we should resolve?
• Matthew: How’s that going to help with platform implementations?
• Lee: Android wants browsers to pass through instead of blocking anything. Also important forcross-device. Otherwise, we might end up with custom URI schemes for those situations.
• Wendy and others: W3C should chime in
• Nick: Feature detecting the existence of a particular wallet app on the device would indeed be asubstantial privacy concern.
• Ryan: Agree with Wendy. In particular, why the browsers want to be able to block specific protocols,and why that cannot be handled between the verifier and the wallet based on their needs andrequirements.
• Rick: Concerned that people will fall back to custom schemes.
• Tim: Punt for right now.

Presentation request format validation (#152)

• Sam: Close and resolve this at the protocol level.
• Others: SG

Define a well-known way for a verifier to indicate registration, validation, trustmark assurances, or other necessary info (#136)

• Tim: Suggest to move the discussion at protocol level
• Rick: Should embed some recommendations in the privacy considerations?
• Paolo: EUDI has RP registration certificates.

Digital credential API should support requests for directed identifiers (#126)

• Tim: Old issue. Suggest closure.
• No objection.