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

> This makes it impossible for the existing credential to remain compliant with the spec after this change.
We shouldn't ignore the fact that these types of multi-device credentials are currently opt-in; they're not representative of functionality that's GA.

I believe we should keep the immutability of the BE flag, and continue to allow BE of 0 to mean "not eligible for backup" because it will accurately represent more credentials than changing plans so BE of 1 means "hardware backed"; the latter leaves existing security keys in a weird state (to @emlun's point).

What if instead we start suggesting ways in which RP's can detect these "beta" credentials to retire or accept updated flags for accordingly. For example:

> If a credential with `"internal"` transport is successfully used for auth in Safari on macOS after X date (whenever Apple's passkeys go GA), and it happens to come back with BE of 1 and BS of 1, then it's likely Apple successfully updated their implementation of the spec and it should be safe to update the RP's knowledge of the credential's flags accordingly. In all other browsers and OS's, this should result in a failure because no one else is demonstrating multi-device credentials.

There's undeniably going to be a transition period because of how easy it's been for nerds like me to opt in and how impossible it's been for RP's to know a multi-device credential from a single-device credential. If someone opts into a beta technology they have to expect some rough spots along the way. Why not lean into that a little before we make a spec decision that'll make the spec even trickier to consume?

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


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

Received on Thursday, 14 April 2022 04:05:39 UTC