-
Notifications
You must be signed in to change notification settings - Fork 9
2024 05 01 Meeting Notes
Organizer: Tim Cappalli
Scribe: Wendy
- 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?
- Anyone from Chromium or WebKit have any updates?
- 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
- 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)
Heather: Welcome, Code of Conduct reminder
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/
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.
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
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
Heather: can this be closed?
Tobias: I think so, based on IIW conversation. I’ll ping Torsten
Rbyers: I think we need Apple for this one
Tobias: Agree. I opened a related issue, https://github.com/WICG/digital-identities/issues/100
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.
Rbyers: Tobias’s issue relating to extensibility
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.
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