-
Notifications
You must be signed in to change notification settings - Fork 9
2023 10 18 Meeting Notes
Reminders: WICG member: https://www.w3.org/community/wicg/
W3C Code of Ethics and Professional Conduct: https://www.w3.org/Consortium/cepc/
Organizer: Tim Cappalli
Scribe: Heather Flanagan
- Administrivia
- Intros from new folks
- Issues / topics discussed at IIW
- [Discuss] Credential selection vs. wallet selection
- [Discuss] Query languages
- [Discuss] Should multiple wallets be supported in the same ceremony?
- [Discuss] Solution scope
- [Discuss] Common vocabulary/terminology > any volunteers?
Introductions to all the new people (Heather Flanagan, Ben VanderSloot)
(Tim) IIW conversations - four discussion item issues were covered in some fashion at IIW.
(Tim) Lee and Sam demo’d what’s being deployed in Android. Session ended with two things on the screen: an android disambiguation UI and a more “intelligent platform assisted” credential selection platform selector. Question at the end of the session: does anyone prefer the android disambiguation model? No hands in the IIW meeting. Had some commitment to go test the intelligent platform assisted platform.
(John) Consensus was that the picker should do the picking based on the desired credential and then hand off to the wallet to fulfil the request, up to and including handing back an opaque blob of data. There was a sense that it should be up to the wallet to return appropriate info to the verifier so other protocols/communications could happen.
(Sam) in that topic, something Lee brought up at IIW - the fact that if you just return the reference to the wallet, then the wallet announces itself to the verifier. Whereas if the OS/platform talks directly to the wallet, it can do that without revealing info about the wallet. There are different privacy properties about how much the verifier learns about the wallet.
(John) in some cases, not showing what the wallet is might be a privacy advantage, but in other cases it might be a requirement. We need to leave open both possibilities. This could be used to support an IdP chooser as well because it’s protocol independent. In SAML you have to know both parties for it to work. If we can keep the verifier from knowing who the wallet is, that may be a better pattern, but it won’t work all the time. This is about releasing info AFTER the user consents, never before.
(Lee) probably won’t have a protocol where the wallet is always revealed.
(John) agree; we should have the ability to return a credential
(Nick) we shouldn’t always reveal the issuer.
(John) in a three-party trust model, what would be the meaning of the credential if you don’t know what the issuer is?
(Nick) it could be one of a group of issuers (e.g., one of several states without revealing my state)
(John) there has to be some kind of trust binding possible
(David) there could be a zero knowledge thing and an intermediate that says “I saw an issuer that I trust”
(Lee) at some point you have to trust someone making a statement.
(Tim) plan with the issue is to put a summary from IIW and this meeting and then wrap it up in about two weeks if there are no further discussions.
(David) Credential selection vs wallet selection - you want to allow a user agent to use credential selection, but there should be an opportunity to do wallet selection such that that’s all they see.
(Lee) would like to be more opinionated about this. Not sure wallet selection meets the bar of user information.
(David) not sure what level we’r emaking requirements.
(Lee) the user agent has a responsibility to help the user figure out what they’re going with. So there will be requirements in the initial selection screen, which has to live in the platform somewhere. We could leave it to the user agents, but it would be nice to set some expectation, possibly at the API so that the platform can do credential selection at a sensible way.
(John) we’re talking about credential selection without knowing what the credential is. The platform won’t have to know the details of the credential; it will select the wallet and says “this was the request I received which caused me to create a card the user selected”
(Lee) maybe what we should say is that the API should be specified in a way that platforms that want to do credential selection can do it in a standardized manner.
(Tim) W3C specs don’t generally define UI.
(Marcos) hearing a lot of the same discussion we had with payment request discussion. In terms of UI, we can suggest various things but we won’t specify details. For privacy and security considerations can suggest what’s important to users. For the model, it’s interesting to hear how much overlap there is with the payments work done previously.
(Hisham) Agree with Lee - we should make sur ethe API definition does not prevent credential or wallet selection.
(Nick) should we talk about attribute property elements? Should the UI help negotiate which part of the credential will be handed over? Or will the UI say “here are all the attributes, but we’ll hand you over for more detailed selection”
(Lee) when you share credential selection, the user should have as much info as possible to make an informed decision, which includes the attributes being requested. You could have multiple credentials and may share different things depending on what you pick. When it comes to an API spec, my request would be enough info in the query to allow the platform to tell the user what attributes match against it.
(John) agree in principle, but given limitations of web assembly, can only do a reasonable first pass of web assembly
(Lee) that’s an android specific tool; this won’t be limited to that
(John) the wallet should learn directly what was requested by the verifier. There should be limited execution that says “yes I have the credential and attributes, but until you get to the wallet that can in turn verify a trust mark, no info will be shared” Don’t want to lock users into the limitations of the selector while letting the selector offer as much info as possible
(Lee) how we thought about it in android: no wallet on the system should allow about the requests being made unless the user selects a credential in that wallet. If the request comes in, though, we have to ask if the wallets can honor that request. So android runs wallet matching code in a sandbox so it can’t talk to the outside world or store anything to disk, so it can’t learn. We do want a principle that wallets don’t find out anything about the request unless the user picks something in that wallet.
(Sam) circling back to the original question, one of the intuitions we’re forming is a distinction between credential selection and authorization to share that information with the verifier. There is some trust you can put in the wallet because it is happening on behalf of the user (since they installed it). So, the intuition is to allow the user agent to do credential selection while always imposing the wallet to display a UI to get confirmation from the user to share it with the verifier. It is always a two-step process.
(Nick) concern is that the choice of which attributes to share back to the RP requires context about the web page and the request, and yet we’re trying to insulate that information from the wallet.
(Sam) in the selector, maybe we can show some UI that says “select one of th eoptions to share with origin.com” and then it shoes a list. So it knows enough about the verifier
(Nick) but if the user isn’t showing which attribute until they get into the wallet UI, the wallet UI can’t help them with what’s being requested by the verifier.
(Sam) pull selection, the wallet gets every info about the selector
(Nick) ok, so after selection, would not try to separate the RP and wallet any more
(Sam) Yes. That is the privacy boundary.
(Nick) There could be privacy reasons you don’t want to allow the wallet to know everything at any point; there are scenarios where the user would always wna tth ewallet to be in an offline state.
(Sam) That is plausible, but we’re so far our effort has been to keep the issuer blind, not necessarily the wallet.
(John) that’s correct in the three-party model.
(Lee) if you think about replay resistance, if you sign the origin into the reply, you have to share info about who is doing the signing. If the issuer and the wallet are the same entity, it gets a little weird. In some regions the legislation says the wallet has to keep a log so the user can see what the wallet has released.
(Gareth) and this is why we need to be able to support more than one wallet.
(David) whatever we’re building in Android, when the user sees the credential, sees what is requested, sees the RP, that is a consent moment. This could be a moment where biometrics are used to help respond to the consent moment.
(Lee) I don’t think it matters fo rthis specification; we wouldn’t be determing at the platform level how it interacts with the wallet.
(John) the wallet will chose what verifiers it works with. It may have different kinds of user verification, or a simple verifiable credential that’s a pseudonymous-pairwise credential which involves small almost nonexistent consent.
(Tim) will add a summary to the issue
(Tim) Skipping this for now
(Tim) should multiple wallets be supported in the same ceremony?
(Lee) if you are doing credential selection, that implies you are going to return one credential but it may be in any one wallet (of many).
(Tim) for requests yes, for responses no.
(Hicham) What are we trying to solve here?
(Tim) Should you be able to get different parts of different credentials from different wallets?
(HIcham) that overlaps with the multiple credential issue
(Lee) having a response from more than one wallet would be too hard.
(Hicham) agree. Start with one credential, one wallet.
(Tim) will add a summary to the issue
(Tim) one of Manu’s major concerns is how web wallets would plug in. How does a web wallet register with the browser/OS? How does the web wallet answer the response? Web wallets are in scope, but we probably have to tackle one piece of the work
(Lee) priority-wise, we’ll do an API for them after we get the rest of the work done.
(John) the initial pass should be if the web wallet has a native app to do the selection, that selector should work. (A web wallet is a SPA that is bound to some web origin. It would show in browser UI.)
(Tim) one example - the minimum bar would be a browser wallet would have to register as a PWA.
(John) no pushback on requiring a PWA.
(Lee) why people cared about it: how can we serve users that don’t have their own phones? the EU pilots have a requirement where users have to be able to use a public computer.
(John) premise that web wallets in the DCEU is that web wallets would be authenticated.
(Lee) there is a reasonable use case for these.
(Marcos) feeling that shouldn’t be in scope. Payment handlers were a disaster from a security perspective; this might drive us into a rathole. Maybe move it out of scope until we get the simpler case.
(Lee) entirely out of scope or deprioritized such that we’ll only cover it later
(Marcos) keep the model in place that describes the qualities of what handles these requests, but don’t focus our energy on taht at this point
(John) not asking energy be focused on that now. We’re asking people not to design things that would permanently exclude them.
(Marcos) on board with that.
(Lee) low priority, not focused on now, but not preventing
(Sam) Chrome will follow demand. Wouldn’t go as far as Lee as saying not now; if there is enough interest in web wallets we’ll look at this, but we’re not seeing the demand yet.
(Tim) any pointers from the payment handler work we can learn from?
(Marcos) will add to the issue.
(Tim) do people who had concerns about the scope now have a better handle on what we’re trying to accomplish? [silence]
(Lee) at IIW, several people said if you only solve presentation, that doesn’t help. Need to solve isusance as well. There needs to be an API to do this. should that be in scope?
(John) there may be levels of that, offering to register a credential and letting wallets say they could do that rather than trying to build a provisioning API.
(Tim) it’s wallet selection for an offer of issuance
(John) it’s an offer that I could issue this credential to someone who is interested; that’s in scope rather than building an issuance API.
(Lee) working assumption was that this wasn’ tin scope, but maybe it will be
(Ben) there is a question about what the request would look like and how the credential itself would be shared to store it. Do not want to say being issued a credential and blindly offering that to wallets.
(John) could have an intermediate application provided by the wallet to see those details, but would then only offer the credential to the wallet after further vetting.
(Tim) thinking higher level, from IIW there is interest and pointed comment we won’t use it if it’s just presentation
(Hicham) to progress we should separate the scopes; issuance is too big a thing
(Lee) that was my take pre-IIW. If we take it out of this group, we still need to talk about it somewhere.
(Tim) is it blocking work? This becomes really important when we get to a charter discussion.
(John) it shouldn’t be blocking, but don’t have a better place to talk about it.
(Tim) so, off the short term agenda.
(Tim) many groups coming from different areas have different terms (or the same terms!) that need to be clarified
(Sam) happy to collect the terms as we’ve been using them internally. Lee can help.
(Tim) start in a google doc and add that link to the issue.
(Sam) a concrete example - how ISO and presentation exchange call optionality and criticality different things.
(Tim) will review on the next call
Next call is on Monday, 23 October, and is an “A” call.
Please add your name and affiliation
- Nick Doty (CDT)
- Hicham Lozi (Apple)
- Benjamin VanderSloot (Mozilla)
- Gareth Oliver (Google)
- John Bradley (Yubico)
- Brian Campbell (Ping)
- Sam Goto (Google - Chrome)
- Tim Cappalli (Microsoft Identity)