Re: [webauthn] backup states in authenticator data (#1695)

> Wouldn't this also imply a change in the attestation chain of the credential when it's restored since it's on a different piece of hardware that has different UV capabilities?

I believe this question is what the [`devicePubKey` extension](https://github.com/w3c/webauthn/pull/1663) is intended to answer - that the attestation for the backed-up key can be "weak", but the `devicePubKey` attestation on each device can give stronger guarantees about the device-bound key.

But it's a good point that we should probably include some guidance or disclaimers about how this interacts with UV. Presumably, a credential restored from backup onto a new authenticator would use whatever UV option(s) available on the new authenticator, unrelated to any UV configured on the original authenticator. So for example, if the original authenticator had a PIN configured, then after restoring the credential onto a new authenticator, the new authenticator may have a different PIN configured or no PIN at all.

Whether my presumption above is accurate or not, I think we should call out in the [User Verification](https://w3c.github.io/webauthn/#user-verification) definition how credential backup is expected to interact with UV. This might relate to `devicePubKey` as well - for example, if an RP is keeping track of which credentials have sent `UV=1` in the past, then the RP may want to track that per device public key for multi-device credentials (because `UV=1` is meaningless the first time on a new device, but meaningful from the second time on).

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1695#issuecomment-1122540194 using your GitHub account


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

Received on Tuesday, 10 May 2022 15:23:53 UTC