-
Notifications
You must be signed in to change notification settings - Fork 9
2024 05 06 Meeting Notes
Organizer: Tim Cappalli
Scribe: Manu
- Administrivia
- 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?
- Federated Identity WG charter update
- iOS cross-platform presentation demo
- Continued discussion
- Wallet-provided nonce (#92)
- mutual authentication (#81)
- New discussion
- Invoked from disconnected document (#112)
- Should response encryption be required (#109)
- TAG security and privacy questionnaire (#111)
- AOB
- Rick Byers (Google Chrome) [1st 25 min only]
- Loffie Jordaan (AAMVA)
- Tim Cappalli (Okta)
- Manu Sporny (Digital Bazaar)
- Wendy Seltzer (Tucows)
- Tyler Minard (Digital Bazaar)
- Hicham Lozi (Apple)
- Lee Campbell (Google/Android)
- Brian Campbell (Ping)
- Wes Smith (Digital Bazaar)
- Joseph Heenan (Authlete/OIDF)
- Heather Flanagan (Spherical Cow Consulting)
- Ted Thibodeau (he/him) (OpenLink Software)
- Helen Qin (Google / Android)
- David Waite (Ping Identity)
- Benjamin VanderSloot (Mozilla)
- Nick Doty (CDT)
Tim: Welcome all, call for Digital Credentials, please put name in attendees list. No administrivia (canceling May 29th call, most will be at Identiverse), will do other two calls this month. New people, any introductions?
Wes: Hi, Wes, software engineer at Digital Bazaar.
Tyler: Hi, Tyler, software engineer at Digital Bazaar.
Tim: Any updates for incubation, prototyping for wallets, etc.? Any updates from OID4VP? (no updates)
Tim: Any updates on charter? (no updates) Heather: We've been having calls to understand where concerns are; we are not voting on it yet.
Hicham: I can do a demo, Erik as well. Erik: Hi Erik, software engineer at Apple working on Identity Related products. Tim: This is a follow-up from IIW, repeating demo.
Lee: Want to re-show demo from last week?
Manu: Yes, please.
Lee: ok, we'll do our demo after Erik. (fighting with screen sharing permissions)
Erik: Erik, software engineer at Apple, conducts a demo of secure cross-platform sharing of identity documents using Digital Credential API. Google's demo shows off the same technology, but here shows interop using iPhone. Did this demo w/ Google at IIW a few weeks ago. Wanted to show W3C VC API can provide cross-platform flow and cross-device flow.
Erik: This works like passkeys across devices, which use CTAP, put out by FIDO Alliance, to accomplish this. Passkeys are supported across platforms and browsers; standard works well. So, extended CTAP for identity presentment as well. CTAP involves two devices, computer and phone; computer shows QR Code, phone scans, phone provides bluetooth advertisement. Local exchange accomplishes three things: 1) relay server for future comms, 2) device does OOB future key agreement using keypair, 3) using QR Codes + bluetooth, demonstrates the devices are in close proximity to one another. Devices use relay server picked by phone, then two devices can message each other using the relay server. Relay server can't see message contents. Passkeys send messages over tunnels. In this demo, we updated to use JSON protocol to request an identity document and respond with it. This is a proof of concept; messages aren't standardized yet; need to do more work at FIDO to update that spec; defer to Lee for any questions on that.
Erik: Let's jump to the demo. Caveats - this is a prototype, does not fully represent production customer experience, still built on passkeys, can work on various OSes - Linux, Windows, MacOS. Demo is for "spaceship rentals", go to rentals website. They need to verify identity before I can rent, click verify identity button, it shows QR Code (via Digital Credential API). I use iPhone and Apple Wallet, use camera app to scan QR Code, will tap on notification, establish secure connection between devices, communication happens via CTAP, local relay setup, iPhone shows consent sheet for driver's license, same as for wallet from elsewhere, consent sheet shows info - document used for request, data attributes, whether website intends to retain information. Double click side button to authn with FaceID, document encrypted on device, sent back to computer. Encrypted data sent to servers to verify. In the browser, we show passenger details. Now, we can continue the rental process. Shows cross-platform presentment of VC API from Chrome to iPhone. Straightforward experience, increased protection against phishing, any browser, any passkeys, can do cross-device presentment, privacy/security covered/improved.
Tom: Is QR Code required?
Tim: A feature of this protocol that allows devices to be persistently linked, devices can also be pre-linked. If pre-linked, you don't see QR Code. Longer-term, could become Ultra Wide Band, NFC could tap.
Manu: Statement about multiple wallet support? Can I ask that question?
Erik: There is a public statement that Apple has provided, that's all I can say.
Tim: Goal is to get the CTAP stuff done this year at some point, still on track.
David: Can we open a FIDO issue?
Tim: I'll have PR ready by tomorrow-ish, do we still need an issue?
David: No, just making sure it's being tracked.
Brian: Can you explain further, who is encrypting to whom? Maybe I don't understand CTAP; when is encryption happening?
Erik: There are two levels of encryption: encryption of tunnel over relay server (CTAP), encrypted end-to-end, separate layer of encryption in demo, document is encrypted to relying party. Document has to pass over encrypted protocol.
Tim: Intent of encryption over tunnel service is to prevent relay servers seeing what's going on.
Brian: Right, 2nd layer of encryption is being discussed as what's required? What protocol over Browser API is this running on?
Lee: Demo preview protocol, which was shown at IIW. Anything that you can pass into VC API is passed over.
Orie: For the message layer encryption, how is key establishment done? Where can I find more about that?
Tim: Keys for CTAP layer?
Orie: No, CTAP channel encryption and protocol specific message encryption. CTAP has key discovery. What about key wallet uses for encryption?
Erik: For this demo, this is out of scope, that discussion getting shaken out on what Document encryption will look like.
Hicham: We encrypted with HPKE for the demo, it wasn't our goal to set something, we're still discussing.
Lee: Ok, we'll do our demo now.
Lee: This is our test page, you can see this yourself by doing the demo. Show request preview - preview protocol to test inside WG, not standardized, exercise the API. The other one is OID4VP, this is the current proposal, Torsten has a proposal, this is how you do OID4VP over browser API. We can make a request, request mdoc with those attributes, selector pops up, two wallets, support multiple wallets, each one returned matching credential, attributes requested, same-ish as iPhone. We do a biometric authn. User data pops up, returns back to website, website decrypts and shows data.
Lee: Next demo is on spaceship rentals site, same website, same scan of QR Code, same prompt, and CTAP connection, same prompt and same thing you see locally, click continue, do biometrics, CTAP transmission happens and you get credential on website. We think by doing this we can demonstrate a viable way to do cross-device presentment.
Manu: What about same-device flows?
Lee: Yeah, you can use VC API, it just doesn't use CTAP. Wallet UI is shown on screen; all wallet is doing is biometric prompt. Real world wallets would show UI, wallet gets to take over UI (consent requested), biometric prompts, wallet UI, when we consent, biometric consent is done via wallet app.
Manu: What about web-based wallets?
Lee: No objection at present, but could be done in the future?
Tim: Need to ensure a web-based wallet (could be extension or PWA) can answer requests across the device. Similar to a current issue with passkeys with web-based providers. Need a non-web exposed API to all credential managers (e.g. wallets or passkey providers) to register with the browser, who can then register with the platform. This ensures those credential providers can handle requests from other browsers and native native apps, as well as cross-device requests. I am planning on writing an explainer to talk about this in the context of both passkeys and digital credentials.
Lee: Same back-end can work for native and web-based apps. If we have web-based wallets, we need to solve them for web-wallets as well. We need all of them to use the same API.
Tim: That might not seem like a big concern, when that's the only way you can sign in, browser extension is not useful if you're tied to
Hicham: To be clear, we didn't say anything about how it would work. Different, disagreement, we didn't say implementation plans, can only point to statement below:
Apple statement being referred to: https://developer.apple.com/wallet/get-started-with-verify-with-wallet/
Manu: Ok, so what I'm hearing is it would be nice to have the same solution for web-based and native-based apps using Passkey or DC API pathways - a common problem across APIs.
Tim: Yes, acceptable summary.
Benjamin: Poke at mdocs; even w/ selective disclosure, they're uniquely identifiable by issuer. If we want to consider that a threat model, that might be out of scope for what we want to talk about here.
Lee: That's more of a credential format question. Point taken, a bit out of scope, but point taken.
Benjamin: Having de-identification possible is something you have to consider with regard to UX we're enabling. I understand that's out of API shape.
Tim: Thanks all for those demos.
Tim: Discussed on last call, waiting on Torsten to close, maybe we have to let this one ride. Can we write something on issue or close this?
Lee: Let's wait for Torsten to update it.
Tim: Paolo opened this one, thread veered off topic for a bit. The API could participate in this, Paolo is on. Wondering if there are open questions, summarize, close or leave it? QWACs come up, origin (resolved at this point), last question is: How to convey a higher-strength server identity? Maybe covered by OID4VP work? Do we need to leave this open?
Lee: Should RP be required to verify wallet - no trust issuer, don't need to also trust wallet? API can easily support that. ARF implies you need to validate the wallet, is that in scope?
Paolo: The beginning was our thinking, ask wallet to implement a mechanism to allow RP to authenticate wallet. Mutual authentication, not necessarily mandatory for every interaction, if requested by RP, might be requested to present. Dedicated attestation, how could this be implemented without adding too much complexity? Our requirement to authenticate wallet from RP. Might be possible to request through OID4VP.
Lee: There are concerns on our side, privacy - identity of wallet, just need age from something, revealing that you have a "German wallet" reveals that you're a German citizen. Awkward from a privacy point of view. From protocol point of view, platform attestations, platform specific, tricky one to solve in a reliable, platform agnostic way.
Paolo: Open discussion, we don't want to violate privacy, we have some proposals in v1.4 ARF wallet instant attestation, wallet provider, where there is no info about wallet itself, attestation genuine wallet, attested by wallet, open discussion, for us it's a requirement that we need to put in place, then it's up to an RP to decide if it's not always needed.
Joseph: Our working theory in DCP WG is we can solve this in OID4VP, we do have an issue there ( https://github.com/openid/OpenID4VP/issues/141), wallet attestation doesn't necessarily have the privacy concerns that Lee was hinting at. We might not need to do anything at browser level.
Paolo: While at the beginning, we were thinking about mutual auth at TLS level, that solves a lot of problems, revocation, other requirements in regulation ... wallet is compromised, no one should talk to that wallet. That was the reason for opening the issue, relationship w/ browsers, application level, this might not be needed to tackle at browser level.
Manu: Mutual authentication is dangerous. Suggestion that we can ID a wallet well enough to not speak to it again, while at the same time doing ZKP, doesn't jibe. Seems misguided to try to ID wallets individually, since you can't do that w/o raising competition and privacy concerns. Engineers should push back on requirements that can be harmful to the ecosystem, even if regulators have made such rqts.
Paolo: We can discuss how to implement it, does it make any sense to discuss things that are law at this point? I think we can mitigate risks. We are still discussing how to implement it, probably at the protocol level.
Manu: Bad laws go on the books all the time, and this could be one of them. We understand privacy well, and it's our job to push back against potential privacy harms. We shouldn't stop talking because a bad law has been passed. Try to mitigate. Shouldn't just stop at "it's the law"
Hicham: I agree on the risk of privacy on identifying wallet, specifically. RP authentication side, API does fulfill that requirement. Combining origin info from browser/RP, that's on the RP authentication side, IMO. We shouldn't think that it's not solved on the API side.
Tim: OID4VP can provide a signed request.
Tim: New issue around disconnected documents.
Sam: That is likely a corner case, this group wouldn't necessarily have to worry about. We'll try to find resolution on that, can report back to community wrt. Spec PR.
Tim: issue 109, should response encryption be required? Some comments there, web platform definition. Please add comments there, we will revisit that on a future call.
Tim: TAG privacy/security questionnaire, PR, great discussion on these already.
Sam: Please raise awareness on that questionnaire, TAG review is important to get right, also blocking Chrome launch process.
Tim: ok, look at those three between now and next call.