-
Notifications
You must be signed in to change notification settings - Fork 9
2023 10 23 Meeting Notes
Reminders: WICG member: https://www.w3.org/community/wicg/
W3C Code of Ethics and Professional Conduct: https://www.w3.org/Consortium/cepc/
Please use the meeting’s Slack thread for discussions instead of meeting chat
Organizer: Tim / Rick
Scribe: Helen Qin
- Administrivia
- “pending closure” label being used for issues that have been discussed, have general consensus, and are being left open for a final comment period
- Intros from new folks
- Updates from Blink incubation
- Anyone prototyping with their wallet or verifier?
- Discussion
- Abuse prevention and mitigations
- Query language (deferred from last call)
- Check-in on vocab/terminology
- AOB
- Andy / Ryan from NIST
- Andrew Hughes from Ping Identity - working mainly in ISO SC 17 mDL/eID, Kantara Initiative and OIDF
- Orie Steele - VC WG
- Achim - CTO European netID Foundation, co-chair FedID CG
- Martijn Haring - Apple
Rick: anyone prototyping with the Chrome web api?
Sam: a few people playing with the APIs are not in this call. Any against the api?
Orie: JSON LD vs CBOR for SD-JWT. I did a SD-CWT implementation based on SD-JWT.
David: may not be so relevant for the query format in the context of browser apis
Sam: we have a doc with instructions for playing with the APIs. TO summarize what’s needed: a chrome origin trail flag, Android wallet package name allowlist, identity-credentials Android SDK.
Helen: Need to e-mail us to allow-list
Rick: Browser wants to design an api with confidence for the verifier identity. Therefore, require HTTPS. Does this rhymes with work in EU? Do they also require HTTPs?
David: Not sure about OpenId4VP. It’s three party model can learn about origin.
Andrew: It depends. What level of details is going to get into this specifications? There’s other communication channel.
David: Yes. With part 7 you can look at the demain name but you can also look at who it’s signed by.
Nick: ISO standards aren’t published, developed in secret, so can’t speak for that, and it’s not clear this is an appropriate basis for this work. For things published and for work we are doing in public, origin is an important requirement for the user not just to the wallet but to the user. Better than other previously tried alternatives, though still with caveats. Some accountability if the request is misleading and so origin matters to the user.
Rick: We have safe browsing. Mechanism for report phishing and strong warnings. What Nick is talking about probably won’t meet the bar for safe browsing. Might instead just alter the UI frictions as was linked by the issue 35? We believe that we can use UI tools to communicate the risk levels to users. Happy to get thoughts from other people.
Gareth: for in person presentation, increase warnings on the screen if it’s an unknown origin. Also a difference between the content being requested, e.g. age verification vs whole mdl. Also, keep transaction logs of any releases they make to the device.
Nick: I would encourage us to think more than just scary UI. You have to get the UI to look extremely scary before preventing users to get through. User fatigue with such UIs. Might be reasons to say APIs are just unavailable in certain scenarios. In cases of unknown, don’t even ask users. Should look and understand at the EU model and regulation requirements: might be a pre-registration model and don’t release the request for unknown.
Rick: Push notifications precedents: make the UI a lot quieter. If the user is unlikely to use the API, make the UI very “small”. That’s useful for mitigating concerns. What if a wallet has less trust for an origin; what if all wallets refuse to fulfill a request coming from a verifier.
Achim: Reasonable to deny the request and don’t show anything at all. For openid4vp there’s already a well established 3 party model. You’re bringing another party into play can be a complicated mix.
Andrew: within the UI do you expect a handoff of the control of the UI once it’s been selected by the user.
Achim: EU wallets have to work cohesively across platforms following the EU regulation and have to gain control of the UI upon selection
David: Good point. If you look at our demo: the wallets get involved in 2 places: Android system UI information is populated by the wallet in a sandbox. Once the user is informed by the UI and chooses a wallet then the wallet gains UI control, can do face-auth or additional warnings etc. Therefore, system UI and wallet UI are not fundamentally incompatible
Achim: Europe has low / high level of authentication. It’s difficult to get a high level of authentication from the platform authenticator.
David: Android has plans to improve this too. Agreed
Rick: should it be part of the API for the verifier to indicate the purpose of the request. Should we define this purpose?
Nick: the user at the time of ceremony has some idea about presenting a credential to rp / website. Once you hand it to the wallet it might be too late. It’s gonna be hard for user agents to confirm that the HTML was successfully used for conveying the purpose. Might be enumeration, or string of text as a clear value for purpose.
Sam: Interested. “By the time a request gets to the wallet, it’s a bit too late”. How should we think of the role of the wallets in terms of protecting the users versus the browser’s role.
Nick: Good to define and write this down. I was imagining that the user agent (browser) has a pretty significant role because the request is going to be initiated on a website and because the browser knows the context and preceding actions. You’re browsing and you get an immediate pop up, the wallet is in a separate app and it’s hard for that app alone to tell what’s happening, what’s being requested and why/whether it’s safe. So browser has a role.
Rick: agreed not sure that it’s possible to avoid it completely. Our design has blurred the line by adopting credential selection over wallet selection. The wallets are going to have to deals with issuers
Nick: that won’t be user controlled
Rick: at least for high value issuers / high value credentials are going to issue to wallets with high assurance
David: Receipt model? Keep a log of all the records of request and fulfillment. https://www.iso.org/standard/80392.html
Sam: Extensibility for the ecosystem is important to us. If the browser needs to understand everything, browsers will only understand so many things and can anticipate so many use cases. Want to also give the ecosystem the ability to extend.
Rick: issue 31 query languages
Orie: languages tend to be credential format specific but you have also desire to support multiple credential formats. If your goal is format agnostic, how many different types you plan to support? Different de/serializations and for supporting those can quickly be hard and a problem.
Sam: Say mdoc & VCs the browsers will have to understand both of them and the query languages for both of them. Understanding just one query language is better than understanding one query language per format in that sense, for browsers. There’s an extensibility tension here.
David: One concern with presentation exchange is displaying strings to the user from the verifier that might be dangerous. https://identity.foundation/presentation-exchange/
Rick: chrome is not allowed to do it: to display to user strings from untrusted source
David: we did some work in ISO about criticality (called “optional” in PE) and oneOf (for the RP to express it needs just one of a prioritized list of attributes) and found the work should be simple. Not sure if PE supports this, will need to check.
Martijn: agreed with David. Not much necessity for a very complicated request structures. Vast majority can be solved by a simple request format. Might save time to focus on just a few request formats
Rick: Chrome agrees that we don’t plan to support every use case possible. Maybe we should agree and be ok with focusing on the major use cases. Andrew: completely reasonable to iterate. If you allow the query to take place in the wallet, the platform can’t enforce the user protection. Initially what you suggested sounded like after the wallet selection and the APIs, there will be additional message afterwards.
Rick: possible but a tradeoff. E.g. the response might be encrypted and the ecosystem will not understand it by design.
Please add your name and affiliation
- Sam Goto (Google Chrome)
- Orie Steele (Transmute)
- Rick Byers (Google Chrome)
- Loffie Jordaan (AAMVA)
- Nick Doty (CDT)
- Achim Schlosser(European netID Foundation)
- Helen Qin (Google / Android)
- Andrew Hughes (Ping Identity)
- Andrew Regenscheid (NIST)
- Ryan Galluzzo (NIST)
- Hicham Lozi (Apple)
- Martijn Haring (Apple)
- David Zeuthen (Google)