-
Notifications
You must be signed in to change notification settings - Fork 9
2024 05 15 Meeting Notes
Organizer: Tim Cappalli
Scribe: Sam and Manu
- Administrivia
- WICG Digital Credentials F2F on 6/21/24 in Mountain View (co-located with joint Fed ID CG/WG meeting on 6/20/24)
- GitHub repo renamed https://github.com/WICG/digital-credentials (thank you Marcos!)
- 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
- Continued discussion
- Wallet-provided nonce (#92)
- Torsten - good to close this?
- mutual authentication (#81)
- Is there agreement that this is handled at the credential exchange protocol layer?
- Consider applying the robustness principle with regard to user agent request validation (#100)
- New text added to the explainer. Can this issue be closed?
- Wallet-provided nonce (#92)
- New discussion
- Most users will experience a no-matching-credential dead-end (#104)
- TPAC planning
- AOB
- Heather Flanagan (Spherical Cow Consulting)
- Helen Qin - Google/Android
- Orie Steele - Transmute
- Mike Jones - Self-Issued Consulting
- Nick Doty (CDT)
- Manu Sporny (Digital Bazaar)
- Wendy Seltzer (Tucows)
- Joseph Heenan (Authlete / OIDF)
- Hicham Lozi (Apple)
- Hiroyuki Sano (Sony Group)
- Lee Campbell (Google/Android)
- Sam Goto (Google Chrome)
- Clecio
- Marcos Caceres (Apple)
- Hicham Lozi (Apple)
WICG Digital Credentials F2F on 6/21/24 in Mountain View (co-located with joint Fed ID CG/WG meeting on 6/20/24)
Heather kicks off the call
Heather: We operate under a code of conduct, please read the new one.
Heather: We will meet in Google, Mountain View California, on June 21st, have a F2F meeting, back-to-back with meeting for FedID CG the day before. Expect a sign up link.
Mike Jones: Event that this is co-located with?
Heather: We wanted to have something before TPAC, handful of people, spec editors, that needed to be available, between those two things, we couldn't do anything in July (Spec editors out), August too close to TPAC, but wanted to get something that had Sam and Marcos there. Those things drove the meeting.
Heather: Thank you, Marcos, for updating name of Github repository.
Heather: Anyone new on the call?
Clecio: I work with Government of BC, involved w/ BC Wallet and Open Wallet Foundation and interested in this WG.
Sam: Some small update, updating request to take object instead of string to become spec compliant. Technically breaking change, but hopefully it'll work well. That's the only big change. We also moved a couple of CLs that puts up an interstitial when requests are privacy concerning, will let Rick come back and present privacy mitigations we're considering, maybe that's a topic on its own?
Marcos: Implementation work continues, no significant updates at this point. Patches continue to go into WebKit.
Manu: we made this announcement I think last week, but we’ve been working with the state of California, https://lists.w3.org/Archives/Public/public-credentials/2024May/0016.html https://github.com/stateofca/opencred in a platform called OpenCreds, announcement there, and an open source repo, fundamentally, two announcements in one, the state of California is issuing their DL in a W3C Verifiable Credential, in production today, in the DMV app, along another VC, the TrueAge credential. In the verifier side of things, the OpenCred, speaks all sorts of protocol, OID4CVP, CHAPI, and there is an intent to make it speak the DC API, of course, just general announcement that we are working on that, no timeline,but we do plan to track to what this group is doing and prototype and deploy what this group is designing.
Heather: Other questions or updates?
Manu: we are not using the API right now, but we are planning to. Not today, but we will be using the DC API in any form.
Nick: is that for in person?
Manu: not for in person, online only.
Heather: Since Manu mentioned OID4VP, do we have updates from DCP WG?
Not hearing any updates from DCP WG
Heather: The W3C Staff, Wendy, and I have been on several calls on charter text as it was put out for consideration. Simone is thinking about a revision and what to put out there, that conversation will continue for a little while, will require Horizontal Review, and other things in progress, do not expect the charter to be revised by time we have face to face.
Manu: where do you think it is going? What are the things that you heard the most? Generalize?
Heather: I heard basically two things: concern about the maturity of the API, not sure if we want it standardized at all, resistance to move to a WG, more significantly, the bigger picture considerations, not so much of the digital credentials work, but more generally identity on the web. Touches upon several different working groups, such as VC WG, FedID WG, the Privacy WG, something needs to be formed, but we don’t know what.
Heather: Any other questions?
Nick: don't expect it to be revised? or don't expect a revised version to be approved by W3C Advisory Committee?
Heather: Charter is under discussion, we're trying to be public about discussion, concern was that adding DC API into any WG Charter is premature - one concern raised.
Nick: You said Simone might have a new version as of tomorrow? Approved?
Heather: We are not going to have a revised version. The calendar doesn't work out, it'll just be for discussion
Heather: open issues
Heather: Wallet provided nonce
Heather: we’ll come back to this later. Anyone with more recent information?
Heather: Mutual authentication - mutual authentication (#81)
Heather: anyone?
Hicham: I’m not a fan of this whole wallet instance authentication, it should be built as part of the issuance. It is going to make things complicated. If we have to do it, e.g. legislation, we’ll have to think about something simple … i think we should try to not add another cryptographic mechanism, because it will add significant complexity. We should try to achieve this with issuer data authentication, wallet key part of the credential
Lee: I agree, I don’t think this belongs to the top level … it is basically the app name of the wallet, authentication … it is a privacy leak, we shouldn’t do unless we have to … privacy and fragmentation and prevent rp filtering on them, i don’t think we want to go down that path. If we going to do that, we should do that at the issuance … the issuer at that point, of issuance, can decide … paolo is saying something even stronger, in eiDAS somewhere you have to verify the instance of the wallet, not sure why … the wallet can attest itself to the issuer … an extra bit in your assertion, that was a wallet that was attested in a large list of approved wallets … not something that we want to handle in our API
Manu: +1 for not being put on at this layer of this API. agree with Hicham and Lee, for different reasons though. Bad privacy leak, there are legislations that are misguided, protecting the users from bad wallets getting into the ecosystem, lets not put that in scope for the DC API.
Lee: and what would an RP do with it, right? A credential that is valid in every way, but the wallet isn’t approved. It’s not something that the RP should have to do with.
Heather: what layer should this be at?
Lee: something at the issuance or credential format level. Anything at the presentation protocol level, that seems also like an anti pattern, to include this in OpenID4VP. Adds a lot of complexity for one. Really difficult to attest the app identity. It is leaking of platform specific details to the web API, it is practically very difficult to do as well.
Joseph: some people were saying that we could do at issuance time, but there are cases where that happens after the issuance, the main thing i wanted to say is that it doesn’t seem to be dealt at this level, probably at the credential format level.
Clecio: I don’t quite understand the problem statement, other than wallet discovery, but what is it intending to solve? Is the assumption that the credential is disconnected
Lee: this API doesn’t cover issuance at the moment, not yet. On the issuance side you have more long lived things, a pretty different API I’d say.
Clecio: but the presentation, identity assurance, it is about keeping the integrity of the identity … the whole flow has to maintain the level of assurance … presentation is in scope … if i’m a verifier … i may need to ask that same question “have you kept the credential at a safe place?”. These questions have to be surfaced somewhere else. I do like this conversation that it is not at this layer.
Lee: yep, outside of this specification I’d say.
Issue 100: Consider applying the robustness principle with regard to user agent request validation (#100)
Heather: anything else? Can we close it?
Manu: if we are going to close it, what’s the action? It seems that Chrome is going to be passive, throw interstitials, my interpretation of what Rick mentioned, that’s the path forward, or it is implementation dependent of what’s allowed through, that should result into some spec text, so my question is what spec should we write to close it
Marcos: of course we are going to apply the robustness principle … to manu’s point, we need to look at it in the context of spec text … so we can’t really close it yet … but rest assured that we are well aware of this principle …
Brian: Martin Thompson has written a really thoughtful on the robustness principle, how much we are applying … i don’t have specifics … it feels
Marcos: can you drop a link: https://datatracker.ietf.org/doc/html/draft-thomson-postel-was-wrong-03
Brian: that might even be posted as an RFC
Wendy: https://datatracker.ietf.org/doc/rfc9413/
Lee: Dick brought this up at IIW, one of the big pieces of feedback was that if we call this API, 99% of users are not going to have credentials, and the UI is going to be terrible, so reluctant to put this in the primary flows. I don’t want to call this if it is always going to fail. That’s reasonable feedback.
Lee: on the privacy side, at least at Google, the bar that we are trying to keep is that the verifier should not be able to distinguish between the case when the user had a credential vs declined to present it (e.g. COVID vaccine). We’d like to keep this principle, let us know if you disagree. If you have this principle, you can’t really do what Dick wants.
Lee: because these things are device bound, you have to support some sort of device flow. You have to pop-up some UI to do the cross device. If we didn’t show any UI there … so it does feel like we’d need to show some UI.
Sam: Just a clarification question, Lee? I thought I heard from Dick that it would be sufficient to expose whether or not the user has a wallet vs. has a specific credential?
Lee: That was talked about, on Android, it'll always be "true" – because Wallet will always be installed, same on iPhone (platform wallet always installed).
Sam: Ah, right, interesting – what about wallets with credentials in them?
Lee: Yes, that was the next level down, "Do you have any credential on the device"? How useful of a signal is that over time? There might be reasons why on Android that would return true as well. So, that might be fairly useless over time. As a part of RP, it'll be fairly useless – age verification – app installed on airline, do you have an airline card, well you're probably over age. Not going to be useful in the grand scheme of things.
Nick: Similar feedback, don't know how any boolean signal turns out to be useful, credential that responds to query – serious privacy issue. Other privacy issue – not sure I share the goal, sure websites don't want to make call for people that don't have functionality, that would be slower/annoying, hidden assumption on optional/fast to present credential, but that misudnerstands the high assurance government issued credentials. You shouldn't just say "The user has a credential, let's grab it" – goal is "I've made a decision that I'm filing taxes, etc." and "I have this on my device and made a conscious choice about what I'ma bout to do". That's not the case for a fast operation, the user should be well down the flow.
Lee: Yes, we knew this was a fairly high friction flow, not designed to be a quick clickthrough API, that landed well.
Brian: Wouldn't expectation be around usage of some kind of credential that the website will have to build, it will need to build contextual information, provide optionality, begin user action to start this flow? I kinda understand what Dick is saying, but maybe goes along w/ what Nick was saying, these websites will have to provide some context around why you're doing this and what to expect so they wouldn't click on the button if they don't have a credential.
Lee: More of that context, 4-5 folks that came w/ feedback, they do have legit reasons. Google as verifier, age verification has this problem, we take user down age verification path, number of options, verify by taking pictures of DLs, credit-card based flows, telephone number based flow, and we can add this new flow for govt-issued IDs, if they pick govt' IDs, you'll give them context, then you click a button and then it fails, then you have to get them back to make a different decision. It might be a bit of a pain, people might not know what it is, verify using DL, put blurb to explain it, pretty complex concept, and have a mass of people that can't use it. We are probably not going to make it easier, even if it's inconvenient at this time.
Brian: useful to think about it, but that's probably not a problem API needs to address w/o leaking unacceptable amounts of user information. There are tradeoffs. Any of those flows could result in something bad happening, likely to fail for most users early on.
Sam: I'm a little bit more unsatisfied with the position than Lee is. I still have an intuition about issue, understand privacy tension, do feel that this is a problem that we need to work on. I don't mean to put Mike on the spot, but I remember reading about Infocards early on, but specific call out about why infocards didn't go well, hard for RP to predict whether infocard was available. We don't want to run into that problem again. Benefit of hindsight, any insights?
Mike: The fact that you could get to card selector, and have no cards, and have no way to get them was bad. Even for self-issued cards, UX you could create with self-asserted claims, just as good as FIDO authenticator, over than 97% of the subjects in usability tests did not get through initial flow, had no idea what they were doing, why they were doing it, what it would do for them, even for 3% that got through flows, they would say something like: "How could I have logged in, I didn't type in the password?" – unless people have a good mental model, and it's actionable, it's doomed.
Manu: +1 to what Mike just said, and what Lee was saying before, looking at the implementation we have done before with the CA DMV, we found that a lot of usability testing, we really needed to tell the person what was going to happen, nobody knows how to use these credentials online, changed the screens, you could just take a picture of your driver’s license, take them to a site that clearly highlights, high friction, pre teach the person how to use the app to go through the flow, hand hold them, and tell them that it was successful. Sam, I do agree that we need to think about this, I don’t know that there is much that we can do other than to explain to people what they are going to go through in the flow.
Heather: Good discussion, some stuff to play with in there. Anything else?
Joseph: sound like parts of this can be solved if wallets are able to indicate to the browser that if they don’t have the credential, they can obtain
Lee: like enrolling a credential inline
Lee: at the moment, there is no reason why you can’t do that today.
Lee: it could work … the risk is that all wallets, will all spam, and tell you that they can handle it.
Manu: one philosophy that we can take it here, the website could do some of it other than the API, something to consider.
Heather: last thing, keep it in your heads, we are starting to make plans for TPAC, september in Annaheim in CA, requesting meeting times in advance, figure out what days are available … it is a little hard to plan … will the WG be rechartered, etc. Much we don’t know, but we do expect some kind of meeting … but we’ll let you know as soon as we know what dates/times.
Mike: WebAuthn is also going to meet.
Heather: yep, noted that we shouldn’t try to conflict with that.