Add ability to query for feasibility of registering a credential that is backup eligible

[MasterKale]

Proposed Change

I propose adding a new API to PublicKeyCredential that would allow RP's to determine the feasibility of generating a backup-eligible platform authenticator credential. The majority of our existing platform authenticator credentials are backup-ineligible. It would be desirable for us at Cisco to be able to know ahead of time if we could "upgrade" a user's existing platform credential after a successful auth, without going through an entire registration flow and then rejecting it afterwards because we analyze the flags and see that the new credential is not eligible for backup.

In the spirit of existing methods, I'm thinking of something like PublicKeyCredential.canCreateBackupEligibleCredential() that eventually returns a simple true/false. Perhaps it accepts a single authenticatorAttachment parameter to help future-proof the method for a potential future state where cross-platform authenticators are capable of backing up credentials too.

Alternatively, in the spirit of feedback that @sbweeden has left in a somewhat related issue, this could be addressed by user agent behavior that fails a call to navigator.credentials.create() if some new parameter "backupEligible: true" was passed into the options and it is determined that the platform authenticator could not respect that option (because the backup mechanism is disabled, etc...).

[Firstyear]

Inversely, the opposite behaviour is also desirable where backupEligible: false would prevent the user from using a device that is backup eligible in cases where it's not required.

[MasterKale]

There's a better possibility of this becoming an authentication extension. It'd require successful completion of a call to .get() to expose that data point, so it'd be better for preserving user privacy.

Might also offer insights into the ability to generate both backup-eligible discoverable- and non-discoverable credentials about the authenticator that just completed the authentication. Thus if you saw "can create backup-eligible discoverable credential" and an "authenticator transport" of "internal" there's a strong possibility the RP could lead the user through a registration and replace a be:0 platform authenticator credential with a be:1 platform authenticator credential.

[MasterKale]

Alternatively an RP could simply detect be:0 and naively make another call to .create() with the same user ID and check be flag in the registration response. That wouldn't require any new functionality.

I'll keep this issue open for now while I take this back to my team, and follow up to clarify the ask or simply close this out if it turns out we don't need this functionality after all.

[timcappalli]

Alternatively an RP could simply detect be:0 and naively make another call to .create() with the same user ID and check be flag in the registration response. That wouldn't require any new functionality.

You could do this in combination with Client Hints for platforms with binary behavior.

[sbweeden]

Following TPAC discussion we are going to close this issue. RPs cannot expect an API for detection of BE=1 capable browsers, because with cable/hybrid that would be possible without the browser knowing at the time the API is called (so a browser would always just return "yes, this is possible").

For the alternative case, where an RP wants to request a device-bound credential, the thinking is that this is suggested by the RP by requesting attestation, and the DPK extension. Whether or not platform authenticators actually implement DPK with attestation remains to be seen, but that is the way in which an RP would indicate their desire for an attested device-bound capability.