Re: [webauthn] [Superset] Updating credential metadata and requesting deletion of stale credentials (#1967)

> There are pros and cons to making this an action users have to consent to (and therefore, that we can inform the website that an update took place) vs a silent update. I think I prefer making these updates silently, so that RPs can build whatever experience they want around it, and we don't need to bother users twice. Showing UI for an update would also not be that dissimilar to calling `create` to override an existing passkey. But I would love to hear what RPs think!

I think `delete` here is a bit of a tricky one. For example, a resident key could be stored on a yubikey and *not* attached to the machine when the RP triggers the delete. This would lead to the `delete` call failing, and leaving the rk on the device. Similar, a lot of devices in circulation don't support ctap2.1pre or ctap2.1 anyway, so this delete action may not even work. When this `delete` then fails what does the RP do? Do we delete the credential anyway and then the user has to cleanup in their pwmanager / key manager? Do we insist on the device being attached so we can proceed? I think it's going to be hard to structure a UI/UX here. If we contrast to passwords today, when you change/delete a password in a password manager, the user is expected to cleanup after themself in the pw manager, so I don't know if we should try and do something different here. 

I think `update` however *could* be useful. My concern though is that by having `update` available, rp's will rely on it to be present and will start to store PII in the ID field of the rk expecting they can update it. Contrast to what it *should* be which is an unchanging, permanent, unique id like a uuid. I think update should *only* be able to update the displayName if implemented. 

Where `update` would be useful is for users when they want to change their displayName in the credential since rk's allow the RP displayName to de-sync from the stored displayName in the credential, so having a way to update this would be useful. I'm not sure how an RP would structure this workflow and communicate that to a user though. From a UI/UX perspective a flow to get a user to see that the displayName state is stored in two places, communicating that, and what they need to do would be extremely challenging. 

We're already seeing a ton of issues in adoption of passkeys in general with confusion about how to enable them, how they work, and the ui/ux to even use them to do a login. I think throwing in more elements here could just further damage the situation. 

So from the view of an RP and an RP library, my overall assessment is that while these functions have interesting properties, I likely would not implement them or use them because they risk confusing users. This is similar to my assessment of functions like isUVPAA and isPasskeyAvailable, where these functions only add extra complexity to interactions and workflows, leading to user confusion and rejection of webauth. 


As a more general meta commentary, there are two aspects to standards - the standard as written and envisaged by it's authors, and the standard as actually used. I think that webauthn has a huge surface area in the standard, and really most RP's will only use a fraction of that. So far that surface area at a high level is:

* Create new credentials (nav.cred.create)
* Perform authentication (nav.cred.get)
* Attest hardware security keys (attestation=direct in nav.cred.get).
* to/from base64 for create/get requests.

Outside of those use cases, we have a lot of "fluff" in the spec that the majority of RP's won't ever deploy or use. And the small percentage that do deploy and rely on those fluffy components will run into issues. So we need to ask ourselves is `update` and `delete` just adding more fluff? Or is it going to extend and become something critical that RP's are crying out for? 

-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1967#issuecomment-1747807428 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 4 October 2023 23:53:30 UTC