DRAFT: Backup eligibility parameter during registration #1744
Conversation
|
This type of signal definitely addresses the semantics of what I was asking for in #1739. Attested DPK might also, so I'm not ruling that out just yet. In fact a request with the flag in this proposal could be satisfied by returning the device-bound component in an attested DPK extension response. |
| <xmp class="idl"> | ||
| enum BackupEligibilityRequirement { | ||
| "forbidden", | ||
| "discouraged", |
There was a problem hiding this comment.
I think discouraged and preferred are a bit useless here, since they are wishy-washy. Why would I "discourage" it and how is that different to "any"? I think forbidden, any and required are the only three options we need. 'any' being "let the user decide".
There was a problem hiding this comment.
Yep, that's certainly one of the things to discuss here. But before we dive into details on the design, I'd like to hear whether browsers would be interested in supporting something like this at all.
There was a problem hiding this comment.
I don't see why browser should dictate a feature that is required for RP's to actually work and enforce policy ....
There was a problem hiding this comment.
This is net new. Pre-multi-device credentials, an RP does not know the properties of the authenticator until after the registration ceremony.
There was a problem hiding this comment.
That doesn't mean we can't change this to have a better user experience. For a user to "register" a device and be sent "errors" about their device being ineligible is not a positive experience. Instead we should create a scenario where we guide the UX to only show authenticators that are "very likely" to succeed.
|
This needs strong use cases related to understand what RP's want here with relation to not just backup elligibility, but also attestation. See #1720 (comment) |
|
On 2022-07-13 WG call: the purpose of this PR was to stimulate discussion, and the discussion seems to have died out for now; closing. |
Brainstorm idea for #1739. This is meant to facilitate discussion, not a fully-formed proposal.
Something like this would enable the client to optimize the user interaction to increase the chance that the registration completes successfully. I note in #1714 (comment) that since we now have the
BSandBEflags in the authenticator data, that to me signals that this is a significant credential property that there should perhaps be a feature toggle for.However the argument against (again, see #1714 (comment)) is that we don't want RPs to see this as a "make it more secure" parameter and just set it to
"forbidden"without further consideration. So in order to respect the interests of the user, this proposal allows the client to let the user override the RP's preference if desired.Perhaps something like this could be a reasonable middle-ground? Is the risk of ecosystem fragmentation still too great? Is it not powerful enough to be useful to RPs? Discuss!
Preview | Diff