Inconsistencies in backup state flags

[emlun]

Follow-up to https://github.com/w3c/webauthn/pull/1695#pullrequestreview-1001739999 :

1. §6.1.3. Credential Backup State states:

   The following is a non-normative, non-exhaustive list of how Relying Parties might use these flags:

   However, the described list contains normative SHOULDs.

2. §6.1.3. Credential Backup State states:

   It is RECOMMENDED that Relying Parties store the most recent value of these flags with the user account for future evaluation.

   Which indicates storing both the BE and the BS flags. However, §7.1. Registering a New Credential instructs to store BS but not BE.

[emlun]

I'd be happy to take this on. I propose that

• For (1) we simply remove the "non-normative" claim and keep the normative SHOULDs in the list.
• For (2) we instruct in §7.1. to store the BE flag as well.

@timcappalli any thoughts on this?

[emlun]

Adding on to this, Bikeshed is reporting errors with the new text:

FATAL ERROR: Line 984 isn't indented enough (needs 1 indent) to be valid Markdown:
"   is allowed to be [=backed up=]. Backup eligibility is signaled in [=authenticator data=]'s [=flags=] along with the current [=backup state=]. "
FATAL ERROR: Line 985 isn't indented enough (needs 1 indent) to be valid Markdown:
"   Backup eligibility is a [=credential property=] and is permanent for a given [=public key credential source=]. "
FATAL ERROR: Line 986 isn't indented enough (needs 1 indent) to be valid Markdown:
"   A backup eligible [=public key credential source=] is referred to as a <dfn>multi-device credential</dfn> whereas one that is not "
FATAL ERROR: Line 987 isn't indented enough (needs 1 indent) to be valid Markdown:
"   backup eligible is referred to as a <dfn>single-device credential</dfn>. See also [[#sctn-credential-backup]]."
FATAL ERROR: Line 991 isn't indented enough (needs 1 indent) to be valid Markdown:
"   signaled in [=authenticator data=]'s [=flags=] and can change over time. See also [=backup eligibility=] and [[#sctn-credential-backup]]."

[timcappalli]

I'd be happy to take this on. I propose that

• For (1) we simply remove the "non-normative" claim and keep the normative SHOULDs in the list.
• For (2) we instruct in §7.1. to store the BE flag as well.

@timcappalli any thoughts on this?

1. If there is precedent for this kind of section to be normative, fine with me. I thought this kind of stuff had to be non-normative as they're more or less examples of usage.

2. Yes, no issue with that.

[emlun]

1. I thought this kind of stuff had to be non-normative as they're more or less examples of usage.

Yeah, it doesn't strictly have to, but I can agree for this case. The other option is of course to replace the SHOULDs with non-normative language instead, I'll try out how that works.

[Firstyear]

Agreed, we already store BS and BE in webauthn-rs, and we are able to validate state changes between them are valid transitions. Do we also have guidance around what happens when these flags change, and what are valid transitions? IE if BE is false, and BS changes from false to true?.

[emlun]

Do we also have guidance around what happens when these flags change, and what are valid transitions? IE if BE is false, and BS changes from false to true?.

There is some guidance in §6.1.3. Credential Backup State, but it is not exhaustive and does not currently include guidance on how RPs should handle BE=0; BS=1 or a change in BE. @timcappalli should we add guidance for those cases? If not, there'll likely be wide differences in how implementations handle them.

[timcappalli]

Since the flags are for UX optimizations and business logic, there will naturally be variations in how they're used (or even if they're used at all by some RPs). The use cases cover the ideas that led to their addition to the spec.