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

This came up in [an above discussion thread](https://github.com/w3c/webauthn/pull/1695#discussion_r823287805):

If a credential exists today and supports backup, then its backup eligibility (BE) flag (currently RFU2) will be set to 0 as currently specified. After we change the meaning of that bit, this credential should have its BE flag set to 1 instead. But the current proposal defines that the BE bit is permanent and MUST NOT change. This makes it impossible for the existing credential to remain compliant with the spec after this change.

How do we resolve this? I can see a couple of options:

 1. Allow the BE flag to change from 0 to 1.

    This would effectively redefine BE=0 from "will never be backup eligible" to "is not currently configured to be backed up". Would it also be allowed to change from 1 to 0?

 2. Add an informal note informing RPs that some few credentials' BE flags may change from 0 to 1 during a transitional period as they implement the new requirement, but it's expected that the "will never be backup eligible" promise will become accurate as the feature matures.

 3. @Firstyear [proposes above](https://github.com/w3c/webauthn/pull/1695#discussion_r850033652) to invert the bit: 0 would mean "might support backup" and 1 would mean "will never support backup".

    This would cover the case of already-existing backup eligible credentials, but it would worse represent the vast majority of existing credentials that are not and never will be backup eligible. Those credentials would then be better represented by BE=1, but most hardware authenticators would not be able to make that change.

I'm not sure whether I favour either of (1) and (2). I am against (3) for the reason noted above.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1695#issuecomment-1098669507 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 03:20:37 UTC