2024-05-01 (B Call)

Organizer: Tim Cappalli

Scribe: Wendy

Agenda

• Administrivia
• Intros from new folks
• Cross-device presentation demo (Hicham/Lee/Helen)
• Updates from incubation
  • Anyone from Chromium or WebKit have any updates?
    • [rbyers] proposed security and privacy questionnaire - only think blocking chromium intent to experiment
  • Anyone prototyping with their wallet or verifier?
  • Any updates from the OID4VP workstream in OIDF DCP WG?
• Federated Identity WG charter update
• Wallet-provided nonce (#92)
  • Can this issue be closed based on the discussion at IIW? If so, can the leaders of that discussion add a closing comment?
• Continued discussion
  • Managing request format extensibility without sacrificing security (#102)
  • Tradeoffs of being more or less conservative in DC API velocity (#106)
  • Consider applying the robustness principle with regard to user agent request validation (#100)
• New discussion
  • anyWallet API - true | false (#104)
• AOB

Attendees

• Heather Flanagan (Spherical Cow Consulting)
• Nick Doty (CDT)
• Sam Goto (Google Chrome)
• Rick Byers (Google Chrome)
• John Jordan (Govt of British Columbia)
• Tobias Looker (MATTR)
• Brian Campbell (Ping Identity)
• Wendy Seltzer (Tucows)
• Loffie Jordaan (AAMVA)
• Helen (Google/Android)
• Lee Campbell (Google/Android)
• Ted Thibodeau (he/him) (OpenLink Software)

Notes

Heather: Welcome, Code of Conduct reminder

Intros

John Jordan, Gov’t of British Columbia; executive director of Digital Trust; involved in open source projects, Aries, issues digital credentials; has a wallet in Android and Apple stores. As a government, we’re governed by laws, including privacy; this work is of critical importance. Also concerned with accessibility. https://digital.gov.bc.ca/digital-trust/home/

Demo: do we have the necessary participants? We’ll move later in the agenda

Updates from incubation

Rbyers: I added a PR for TAG S&P questionnaire. Once we get that landed, I’d like to send chromium intent to experiment. Appreciate feedback

Brian: seeing mention of e2e encryption from browser to wallet. Is that a mistake or change?

Rbyers: We don’t require, but “assuming” e2e encryption

Brian: was referring to all the way to the wallet. That probably won’t happen

Rbyers: and later, say request transparency is a feature

Heather: our work is done in public; that depends on keeping issues updated to help the community see what’s happening.

Any updates from OID4VP, DCP

Tobias: Great conversations at IIW around query syntax; taking that back in to the DCP WG, working to update things

John Jordan (intro added above)

Lee: IIW progress on profile for OpenID4VP in browser API. First stab at agreement, v1 of what we’ll send over the API

Tobias: https://github.com/openid/OpenID4VP/pull/155, great progress

FedID WG charter update

Heather: The WG officially formed at the end of March. The first thing we committed to was considering whether this work (Digital Credentials) should move to WG when it’s ready. The WG hasn’t formally met yet. Considering an end-of-June F2F.

Issue in the W3C repository with draft recharter text; open discussion, not yet ready for formal vote. We want to get to a consensus understanding before calling a vote.

Lee: Once we’re in the WG, will we separate calls between WG and CG, work items?

Heather: sometimes. I can imagine arranging calls for separate work items, some joint calls;

Lee: don’t lose the momentum of good attendance on these calls.

Heather: possibly keep this call slot for this work; other FedCM calls; quarterly joint meeting

Tobias: IIW proved how productive in-person events are. Would be great to get another experience like that

Heather: we can also try to co-locate with other identity events that will have critical mass of participation

Wallet-provided nonce (#92)

Heather: can this be closed?

Tobias: I think so, based on IIW conversation. I’ll ping Torsten

Managing request format extensibility without sacrificing security (#102)

Rbyers: I think we need Apple for this one

Tobias: Agree. I opened a related issue, https://github.com/WICG/digital-identities/issues/100

Tradeoffs of being more or less conservative in DC API velocity (#106)

Rbyers: I filed this issue as a place for people to express support for moving quickly; haven’t yet seen them posting. This relates to the charter discussion.

From eIDAS perspective: this is coming; we get to decide how hard it will be to migrate users from custom schemes to API. That’s motivating chromium to move quickly

Heather: heard a perspective of discomfort with the disparity in maturity between FedCM (relatively mature) and this API

John: In Canada, BC has a wallet we’re using, other provinces are also offering wallets. Individuals might have multiple wallets, e.g., BC wallet, Ontario wallet. We’re looking at addressing those. Browser asks OS for info on credentials? OID, didcomm?

Rbyers: suggest starting with the explainer, where we’ve tried to explain, starting from custom schemes,

John: thanks, will try to join more calls

Nick: re velocity question, one concern is we might get stuck, deployment bias. It might be useful if implementers are going ahead, if they can give up-front indication that things will change, including breaking changes, after deployment. To address concerns that we’ll get stuck down a path pre-standard

Rbyers: that’s the rationale for origin-trials, explicit understanding that it’s an experiment, APIs will change in final version

Tobias: Agree with Nick. Like the strategy of trying to break things up in evolution; API features can be layered later. WebAuthn has levels; that’s been a relatively successful design. Velocity, reduce what we need to get consensus on. Explicitly point to evolution in the chartering, commit to evolving.

Consider applying the robustness principle with regard to user agent request validation (#100)

Rbyers: Tobias’s issue relating to extensibility

anyWallet API - true | false (#104)

Rbyers: We’ve heard that chicken/egg problem from lots of people. Verifier doesn't want to send users down dead ends. E.g., age verification has multiple options, verifiers say that if people try one and it fails, they just give up. Brainstorming how to address it. Privacy tension, we don’t want to leak any info to the RP until the user has agreed; and also want to figure out what will work. An adoption concern. The privacy concerns are urgent. I don’t want to add any new privacy risks at this stage. So suggest shelving this for a year or so.

Tobias: hear it in passkeys too, but at least those are origin-bound, so less chance of leakage. A few issues: whether the user has a capable app; has any credentials to present; difficult to resolve.

Nick: potential direction other than anywallet. Even the wallet isn’t enough: they might have a wallet but no credential, or no credential of the right type. DIfferent direction: if users initiate things, then we tend to have fewer privacy concerns. Let the user start a “tell the website” flow. User-initiated presentation, rather than request UI.

Heather: suggest putting that in an issue

Rbyers: I’ll rename this issue to the problem, and suggest we discuss it there. Like WebAuthn conditional UI. other thoughts like a button on the camera app, instead of “take a picture of your DL” use a digital credential.

Ted: big info leakage in making it easy to show a Drivers’ License. That gives lots of usually-unnecessary information.

Rbyers: That’s not how I heard Nick’s suggestion. Would still offer selective disclosure. Aiming to replace showing the full DL

Ted: Look at TruAge. Age verification, minimal info disclosure, actively deployed and in use by millions of convenience stores, today.

Demo

DW: the QR code includes a bluetooth proximity parameter so it can’t be proxied/MITMed to take credentials from local user elsewhere Lee: we had 2 wallets; the wallet not picked learns nothing Nick: would love to see a good explanation to a user to get them to understand and consent