The issue seems to be related to security key. Hence, forwarding the issue to inhouse team for further triaging of the issue.

Thanks...!!

Adam, Kim, do you recall the exact arguments we had for not persisting this setting?

@asayler: When you say "on a per-key basis", do you mean double-keying the permission to the combination of (site, key)? In that case the user would need to have multiple accounts on a given site, each protected by the same set of security keys, to take advantage of the decision being persisted. I wonder, how often would that happen? Also, I think we cannot tell apart different USB security keys at the least.

So the alternative we need to consider here is whether to introduce a content setting that applies to all security keys on a given origin.

The registration action is already heavy-weight. Caching for other permissions makes sense because sites trigger them all the time, but that doesn't work for registration.

Registration is only going to happen a handful of times per-site, per-user, and (very likely) with a different key each time. So the model is more like the file-picker, where each interaction is about permission for a different file/token, than something like Flash permission. (And Flash, even, is moving to an uncached model.)

Also, caching the result would have a low hit-rate and increase the mental complexity on the user: the browser's behaviour now changes over time.

Those arguments make less sense on for demo.yubico.com because, there, people register keys all the time. But the demo-site case is exceptional and we should tune things for regular users.

Thanks for the responses, @engedy and @agl,

While registration is, generally, a low frequency event, I think the use case of setting up a new site and immediately registering 2 or 3 keys would have a better UX if the user only had to respond to this prompt once, vs once per key. As is, it seems like the kind of thing that only going to make U2F adoption more complicated and painful since I imagine most users don't really even understand why this prompt appears or how they should respond to it.

I would also assume that there are many users who have no interest in ever sending an attestation certificate at all, so perhaps you could at least add a global setting to always deny such a request?

Given the potential privacy/fingerprinting implications of sending this info, forcing the user to re-answer this question multiple times with no global opt-out seems both a poor user experience and prone to users making a mistake that might leak data they did not intend to leak.

> While registration is, generally, a low frequency event, I think the use case of setting up a new site and immediately registering 2 or 3 keys would have a better UX if the user only had to respond to this prompt once, vs once per key.

We very much hope that attestation is not generally requested by most sites. Financial sites probably will demand it, but general consumer sites should not.

However, if we make requesting attestation cheaper for sites (because users only see the request once) then that may have the unintended consequence that more sites request it. It's not clear to me which works out better here and we'll probably need a few years more experience to see how things are panning out. But if we switch to caching, we'll never know whether we could have had an influence.

Assigning to Adam to continue the conversation / close out as appropriate.

> While registration is, generally, a low frequency event, I think the use case of setting up a new site and immediately registering 2 or 3 keys would have a better UX if the user only had to respond to this prompt once, vs once per key. 

If the decision is cached on a (site, key) basis, as suggested in #1, the behavior would be identical in this use case, no? It would prompt for all three registrations.

> If the decision is cached on a (site, key) basis, as suggested in #1, the behavior would be identical in this use case, no?

But how do we get a cache-key for a given token? They don't (by design) have unique IDs. We could store a credential ID and ask the key if it recognises it, but that's getting quite complex, esp as resident keys (that may be deleted) start to appear.

Yeah, I was trying to point out that the original suggestion from #1 wouldn't even have the intended UX benefit. But you're right, we couldn't implement that anyway.

I agree that sites generally should not request attestation at all. Is there a reason Chrome can't just put Attestation functionality behind a global option and perhaps even default that setting to off? That would, perhaps, be the best way to discourage its usage.

I think per-site caching would be more semantically useful than per site/key caching, since trust decisions are generally on a per-site basis. And as has been pointed out, per-key caching would require Chrome to be able to track keys on an individual basis which is (ideally) not possible via U2F (although might be possible via other parameters exposed by most keys over USB but not sent as part of the U2F interaction, e.g. the serial number embedded on every Yubikey).

In any case, I appreciate the ecosystem trade offs of various solutions here. If this is intended behavior, that likely answered my question and this can be closed out. I mainly raised this since it was unexpected behavior from the perspective of a seasoned U2F user and likely will be even more confusing to the average or new U2F users.