-
Notifications
You must be signed in to change notification settings - Fork 166
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.
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
Indicate that the credential could be backed up and restored, but not synchronized #1933
Comments
The problem is that backup implies synchronisation here. I think the original flags should have been "sync capable" and "sync active". BS was always intended to be a "user interaction hint" to say "oh maybe you should enable another credential since you current one isn't synced and you should have more than one credential". And if we reverse this lets say I backup my credential and then restore it to a second device. Now I have two copies of that credential, but the "sync" flag isn't set since the second credential believes it was a restore from backup rather than a sync. Yet, now we have two copies of the authenticator, that are indistinguishable. In this case, security conscious providers need to assume BE implies sync even if BS isn't set. In summary, there is no sync without backup. If you can have a backup, it implies sync. BS just says if the sync is currently active or not. |
Synchronization implies that the credential is a kind of multi-device credential. Think about the situation where you only allow one session at a time for the security reasons. |
How would this be done, securely? How can that enforcement logic be guaranteed that a currently active device honestly obeys the command to delete a private key? |
It depends on how the passkey providers mange the credential. There might be a case where the credential is stored in the passkey provider's cloud and the assertion signature might be generated in the secure cloud storage. |
@Firstyear It does not. Sync is one form of backup. The spec does not deal with "sync" deliberately, as it is not relevant to what is being conveyed with the flags. BS is intended to convey that the authenticator believes the credential is survivable against device loss, aka backed up. The fact that a backed up credential is instantly made available on other devices is an implementation decision for user experience.
@Kieun it does not. See above. I disagree with adding additional flags about sync. |
@agl any update? |
This has been discussed in a few working group calls and the consensus was that there is no spec change needed here. Sync is one mechanism of backup. Passkey providers can use the The device supplemental public key (dSPK) can be used to determine if the backed-up credential has synced or otherwise moved to a new device/authenticator. Closing issue. |
Proposed Change
With the passkey introduction and allowing for 3rd party passkey providers to plugin to the platform to manage passkeys for RPs, the WebAuthn credential capabilities might vary across authenticator and passkey providers.
In current Level 3, there is a bit of flags indicating multi-device credential such as
BE
andBS
flags.The
BE
flag indicates that the credential could be backed up and it ismulti-device-credential
.In Section 4, there is defined terminology for
BE
(Backup Eligibility) and Backed Up.The current description for
Backed Up
is as follows.The meaning of backup here is
With this definition, in WebAuthn world, the backup eligibility meaning is that backup itself and additionally synchronization.
Let say some passkey providers would like to offer passkeys with backup and recovery feature and without synchronization.
For example, some of passkey provider application might have strict requirements to have single application instance for the given user.
In this case, the synchronization for passkeys are not provided, but the passkeys need to be recovered if the user lose their phone and buy new one or change their phone.
If this is the case, we need some ways to indicate the credential property which could be backed up and restored, but not synchronized.
The text was updated successfully, but these errors were encountered: