Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DRAFT: Backup eligibility parameter during registration #1744

Closed
wants to merge 1 commit into from
Closed

DRAFT: Backup eligibility parameter during registration #1744

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2769,6 +2769,7 @@ attributes.
DOMString residentKey;
boolean requireResidentKey = false;
DOMString userVerification = "preferred";
DOMString backupEligible = "any";
};
</xmp>

Expand Down Expand Up @@ -2798,6 +2799,12 @@ attributes.
The value SHOULD be a member of {{UserVerificationRequirement}} but [=client platforms=] MUST ignore unknown values, treating an unknown value as if the [=map/exist|member does not exist=].

See {{UserVerificationRequirement}} for the description of {{AuthenticatorSelectionCriteria/userVerification}}'s values and semantics.

: <dfn>backupEligible</dfn>
:: Specifies the extent to which the [=[RP]=] desires to create a [=backup eligible=] [=credential=].
The value SHOULD be a member of {{BackupEligibilityRequirement}} but [=client platforms=] MUST ignore unknown values, treating an unknown value as if the [=map/exist|member does not exist=].

See {{BackupEligibilityRequirement}} for the description of {{AuthenticatorSelectionCriteria/backupEligible}}'s values and semantics.
</div>


Expand Down Expand Up @@ -3414,6 +3421,63 @@ Note: The {{UserVerificationRequirement}} enumeration is deliberately not refere
</div>


### Backup Eligibility Requirement Enumeration (enum <dfn enum>BackupEligibilityRequirement</dfn>) ### {#enum-backupEligibilityRequirement}

<xmp class="idl">
enum BackupEligibilityRequirement {
"forbidden",
"discouraged",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why browser should dictate a feature that is required for RP's to actually work and enforce policy ....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is net new. Pre-multi-device credentials, an RP does not know the properties of the authenticator until after the registration ceremony.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

"any",
"preferred",
"required"
};
</xmp>

A [=[WRP]=] may desire for [=credentials=] to be [=backup eligible=] or not,
and may use this type to express its preference during [=registration=].

Note: The {{BackupEligibilityRequirement}} enumeration is deliberately not referenced, see [[#sct-domstring-backwards-compatibility]].

<div dfn-type="enum-value" dfn-for="BackupEligibilityRequirement">
: <dfn>forbidden</dfn>
:: The [=[RP]=] wants to create a [=single-device credential=] and intends to reject the registration
if a [=multi-device credential=] is created.

The [=client=] SHOULD guide the user to create a [=single-device credential=] if possible.
The [=client=] MAY allow the user to create a [=multi-device credential=] anyway,
but SHOULD warn the user that it is unlikely to be accepted by the [=[RP]=].

: <dfn>discouraged</dfn>
:: The [=[RP]=] prefers to create a [=single-device credential=] but intends to accept the registration
even if a [=multi-device credential=] is created.

The [=client=] SHOULD guide the user to create a [=single-device credential=] if possible.
The [=client=] MAY allow the user to create a [=multi-device credential=] anyway,
and MAY warn the user that it might not be accepted by the [=[RP]=].

: <dfn>any</dfn>
:: The [=[RP]=] has no preference and intends to accept either a [=single-device credential=] or a [=multi-device credential=].

The [=client=] and [=authenticator=] MAY create either a [=single-device credential=] or a [=multi-device credential=].

: <dfn>preferred</dfn>
:: The [=[RP]=] prefers to create a [=multi-device credential=] but intends to accept the registration
even if a [=single-device credential=] is created.

The [=client=] SHOULD guide the user to create a [=multi-device credential=] if possible.
The [=client=] MAY allow the user to create a [=single-device credential=] anyway,
and MAY warn the user that it might not be accepted by the [=[RP]=].

: <dfn>required</dfn>
:: The [=[RP]=] wants to create a [=multi-device credential=] and intends to reject the registration
if a [=single-device credential=] is created.

The [=client=] SHOULD guide the user to create a [=multi-device credential=] if possible.
The [=client=] MAY allow the user to create a [=single-device credential=] anyway,
but SHOULD warn the user that it is unlikely to be accepted by the [=[RP]=].
</div>


## Permissions Policy integration ## {#sctn-permissions-policy}

This specification defines one [=policy-controlled feature=] identified by
Expand Down