2024 06 26 Meeting Notes - WICG/digital-credentials GitHub Wiki

2024-06-26 (A Call)

Organizer: Tim Cappalli

Scribe: Helen

Agenda

  • Administrivia
    • July 1 and July 10 calls canceled, next call July 15
    • 2024-06-24 call is during IETF week. Keep or cancel?
    • Notes from hybrid meeting posted (usual place)
  • Intros from new folks
  • Updates from incubation
    • Anyone from Chromium or WebKit have any updates?
    • Anyone prototyping with their wallet or verifier?
  • Any updates from the OID4VP workstream in OIDF DCP WG?
  • Preview of new Federated Identity WG charter [link]
  • Dedicated call vs existing call for Threat Modeling discussions?
  • Continued discussion
    • What should be the data type for the response? (#119)
    • Most users will experience a no-matching-credential dead-end (#104)
    • Invoked from disconnected document (#112)
    • Nothing is learned without consent (#86)
    • Prioritization of credential providers (#42)
  • New discussion
    • Digital credential API should support requests for directed identifiers (#126)
    • Digital credential API should support identity verification (#127)
    • JFYI: Define error handling (#130)
  • AOB

Attendees

  • Tim Cappalli, Okta
  • Rick Byers (Google Chrome)
  • Nick Doty, CDT
  • Helen Qin, Google / Android
  • Dirk Balfanz (Google)
  • Lee Campbel, Google / Android
  • Ted Thibodeau (he/him) (OpenLink Software)
  • Brian Campbell (Ping “not of the first part of the common name for table tennis” Identity)
  • Wendy Seltzer (Tucows)
  • Hiroyuki Sano (Sony Group)
  • Clecio Varjao (Government of BC)

Notes

Updates from incubation

Rick: Sent intent to experiment. Expecting to start a Chrome origin trial. Working with one partner for one real world use case. Others can sign up too.

Tim: Invite them later to talk about experience?

Rick: Can do.

Lee: Also an opportunity for wallets to respond to these real world use cases.

Tobias: Any change to digital-credentials.dev?

Lee: Expect Chrome string -> object breaking change soon.

Tobias: Encountering an error with the response, so different.

Tobias: Is there trusted issuer validation?

Lee: No

Sam: Origin trails show a level of maturity for privacy and security.

Rick: True, but Chrome also shares the same concerns as Mozilla and others, and the privacy team has only approved experimentation to learn more.

Lee: Android is also officially releasing the native APIs as an alpha release. (Subject to breaking API changes. Same caveats as Chrome origin trials.)

Tim: CTAP PR is done, now goes through WG review. Public draft should be ready in the upcoming month — publicly referenceable but other standards and regulations. Finalized in fall or worst case winter. See more details of the process in the hybrid meeting notes.

Sam: Plan to make the breaking changes (e.g., object request) prior to the chrome origin trial.

Rick: Suggest making digital-credentials.dev work for both cases? E.g., do version check. Where’s the source code?

Lee: Will make the source code public.

Tim: Another option is capability check

Rick: Version check suffices for now.

Tobias: Also not good compatibility for encryption libraries

Lee: Encountered that too.

Tim: Can set up notes / prototype resources and documents on digitalcredentials.dev, similar to passkeys.dev for WebAuthn.

Brain: Where’s HPKE being used?

Tobias: Request encryption with preview protocol

Tobias: About origin trial, will both protocols be supported?

Rick: Chrome doesn’t care about protocol. Meanwhile there are experimental warnings.

Tobias: Flag to suppress the interstitials?

Rick: Yes, the same flag with an option to enable without dialog.

Sam: But real users won’t be able to disable the dialog.

Rick: Yes, but expect the origin trial to be centered around low-risk use cases where the real user shouldn’t see the warnings regardless of the flag.

Any updates from the OID4VP workstream in OIDF DCP WG?

none

Preview of new Federated Identity WG charter

just fyi

Dedicated call vs existing call for Threat Modeling discussions?

Tim: Threat model discussion: one off or use one of these calls?

Room: The latter.

Continued discussion

What should be the data type for the response? (#119)

Tim: during hybrid meeting, consensus on object. please share the word on this issue around the community.

Most users will experience a no-matching-credential dead-end (#104)

Rick: Website should show options for the user to choose. And then the user should see some UI, no UI, and can be an opportunity for cross-device flow.

Helen: No credential dead end UI is going live in Android soon — will see in the next two weeks.

Lee: Today it fails silently but we need to fix that for privacy reasons in time for OT.

Tobias: Concerned that a user might get stuck if they have a credential on another device and aren't given the chance to use it

Tim: same problem exists with passkeys on another device

Invoked from disconnected document (#112)

Rick: Potentially a spec issue on credman, suggest to leave open.

Nothing is learned without consent (#86)

Tim: Seems like a consensus is reached. Hope to close soon.

Rick: Can we have an explainer to capture these conclusions rather than just closing it.

Tim: Already an explainer. Rick to update it?

Rick: Room’s preference?

Tobias: A separate document to capture these non-developer facing context and decisions makes more sense.

Nick: Privacy section, or at minimum very close by, because people can be very surprised if they come across the spec and don’t see any important privacy considerations / design points.

Rick: We have an issue on not having privacy & security consideration sections. Why don’t we add such a section in the spec and link to the explainer until it matures?

Makes sense.

Rick: I will file an issue

Tim: I can help do it.

Prioritization of credential providers (#42)

Tim: Out of scope for API, handled at platform based on context

Lee: Agreed, out of scope. Maybe more in scope for OpenID4VP, want to point out it might be good to support setting a preference for documents.

Tobias: Yes, actively discussed in the query syntax format. Lee: Ordering across different wallets should be underlying platform decisions based on context and user etc, so, out of scope. The ordering of the sequence of documents from a single wallet can be decided by the query syntax.

Tobias: Current thinking of platform ordering?

Lee: Last used, mostly. Still thinking; we don’t have a lot of signals otherwise.

New discussion

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

Sam: Apart from ZKP, no solution other than throwaway credentials for identifiers. Something we haven’t solved.

Lee: Direct identifiers like SSN, it’s universally identifiable and globally trackable. Bad for login use cases. When we say direct identifier, it should be redacted and per RP to prevent tracking. There’s also protocol leaking identifiers like a device key in a protocol. These are two problems.

Tobias: First step is to make the binding unlinkable. Possible, but there's a challenge in adoption.

Nick: Hope you don’t stop pushing on that. Is this issue coming up because of the right to pseudonymity, which goes farther than directed identifiers? Seems like eIDAS also provides a capability for the user to define their own identity, like a pseudonymous name they could enter in their wallet and present in some contexts of their choice.

Lee: Use cases are logins or recovery. But they come with these privacy concerns. Prefer a ZKP solution for such presentment (of, e.g., a drivers license). Also need to make sure this is validatable.

Digital credential API should support identity verification (#127)

Tim: Joseph already commented that OpenID4VP supports this. Ambiguous question that can be closed?

Will leave for 2 weeks and close afterwards.

Nick to comment on this.