digital-credentials
digital-credentials copied to clipboard
WICG
Most users will experience a no-matching-credential dead-end
Many users, and all users initially, won't have any wallets installed on their device.
Letting an app know if there are any wallets lets the app know if the user understands what a wallet is and to not use the API at all.
This single bit of data discloses if functionality will exist.
Agreed we should explore APIs with a single bit of privacy impact. Another option is "has this user ever presented a digital credential before". This is probably sensitive right now given how few users would have either of these bits. But perhaps once we've seen a bit of non-trivial deployment we could explore this. I agree it'll be important for widespread adoption to give verifiers some way to minimize the no-credential friction while also having prominent UI in the likely success case.
Rather than having an API that can be used for gathering 1 bit of data, it would have the same result if invoking the API was a UX no-op if the user had never installed a credential. The app is then learning after the fact if UX was presented -- and UX would be presented even if the request could not be satisfied, but the user had added at least one credential.
This way we don't confuse users that don't understand what a credential is.
We had a similar discussion in the WebAuthn WG about adding a bit to indicate whether the local device had "a credential" for the calling origin. This was a request from @dickhardt in the same F2F discussion.
One major browser engine was not in favor of adding any new silent operations which can disclose user state and another browser engine largely agreed with that sentiment, so the discussion did not proceed further in WebAuthn. Doesn't mean we shouldn't have the discussion, just adding additional context.
From meeting discussion this evening: updating the issue title to reflect the problem rather than just one possible solution.
We've heard from multiple potential verifiers that it's important to them that the "no matching credentials" case tends to be low-friction, especially early when very few users will have matching credentials. They won't adopt an API which adds friction but no value in the majority of cases. But this is in conflict with the privacy requirement not to divulge any information to websites without user permission.
Rather than having an API that can be used for gathering 1 bit of data, it would have the same result if invoking the API was a UX no-op if the user had never installed a credential. The app is then learning after the fact if UX was presented -- and UX would be presented even if the request could not be satisfied, but the user had added at least one credential.
Yeah we've explored that (it was actually our original chromium implementation). The problem is that it's trivial for a site to make a pretty reliable prediction on whether UX was shown by watching the input events that occur on the page. An attacker could invoke a series of requests and watch to see when input behavior changed to indicate the bottom of the screen was now covered in order to learn which sort of credential the user has without the user's permission.
@npdoty makes the good suggestion that perhaps we can address this problem by having the user initiative the presentation rather than the site. For example maybe browsers could have show a button in the URL bar when the page supports digital credentials and the user can choose to tap it. This, of course, has the downside of likely going unnoticed in many cases. But there's a variety of UX design options here.
From a Chrome privacy side, I am not too concerned about revealing 1 bit of information here: it seems an unlikely target for fingerprinting as there would be UX being presented in case the bit was set, and given the variety of wallets, I don't think that this bit reveal anything highly sensitive.
Agreed we should explore APIs with a single bit of privacy impact. Another option is "has this user ever presented a digital credential before". This is probably sensitive right now given how few users would have either of these bits.
Note that if there are very few users using having presented a digital credential before, the entropy of that information is minimal, making it not very useful for tracking at large scale.
Yeah we've explored that (it was actually our original chromium implementation). The problem is that it's trivial for a site to make a pretty reliable prediction on whether UX was shown by watching the input events that occur on the page. An attacker could invoke a series of requests and watch to see when input behavior changed to indicate the bottom of the screen was now covered in order to learn which sort of credential the user has without the user's permission.
If UX was shown then the site did not gather data silently. I'm assuming the user has to dismiss the UX.
My suggestion was that the UX is always shown if the user has any credential, so this does not let an attacker learn which credential, it just lets them know there is a credential, and the user also has learned the site has requested a credential. It is only silent if the user has no credential.
As credentials can be obtained and used in so many ways, does the single bit of information that a user has a credential of some kind, or a wallet app of some kind, help very much with the dead-end problem?
This doesn't seem like a UI that should be triggered frequently, rapidly or without significant set-up around the action.
It certainly helps in the near future when no one has a credential. I would be very reluctant to use the API if 99.99% of the time no one has a credential. And why will someone get a credential if 99.99% of all the sites don't support getting one?
I mind less someone getting UI when they don't have a credential, but have added one. But I don't want to confuse the user that has never added one and does not know what they are.
Depending on what credentials actually get traction, and user's understanding of them, I want more bits of data before I invoke an API that shows UI, but in the near term, it is super unlikely I will invoke the API.
For government-issued credentials with high-assurance personal information, this shouldn't generally be a quick or automatic prompt, or something done on many webpages. Instead, the goal should be that a user has been given a lot of context, and decided to take an intentional action to present an identity document or assertion, and wanting to do so with a digital credential wallet. Given that level of context, I'm not sure I see the size of the marginal benefit to having a button hidden or not.
(Apologies, forgot the follow-up request until now.) My thinking that because this request was likely to be high-context, explained with some alternatives and not something that would be prompted automatically without a considered user decision, that signals about availability of a wallet or a credential would be less necessary for automatically configuring UI, like showing or hiding a button.
what about issuance during presentation scenario? where the wallet is capable of handling credential A, the user does not have that credential in the wallet, but has a wallet installed and is willing to get credential issued into it and than presenting it in response to the presentation request. I assume it could help with adoption if this scenario is supported.
