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.

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

Closed
Kieun opened this issue Jul 27, 2023 · 7 comments
Assignees

Comments

@Kieun
Copy link
Member

Kieun commented Jul 27, 2023

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 and BS flags.
The BE flag indicates that the credential could be backed up and it is multi-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.

Public Key Credential Sources may be backed up in some fashion such that they may become present on an authenticator other than their generating authenticator. Backup can occur via mechanisms including but not limited to peer-to-peer sync, cloud sync, local network sync, and manual import/export. See also § 6.1.3 Credential Backup State.

The meaning of backup here is

  1. Credential could be backed up (exported) and recovered (imported) at some time
  2. Credential could be synchronized with some mechanisms

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.

@Firstyear
Copy link
Contributor

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.

@Kieun
Copy link
Member Author

Kieun commented Jul 27, 2023

Synchronization implies that the credential is a kind of multi-device credential.
But, the passkey providers might have some logics to enforce the credential cannot be activated in the multiple devices at the same time, meaning is that there is no same active credentials on the multiple devices.

Think about the situation where you only allow one session at a time for the security reasons.

@emlun
Copy link
Member

emlun commented Jul 27, 2023

passkey providers might have some logics to enforce the credential cannot be activated in the multiple devices at the same time

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?

@Kieun
Copy link
Member Author

Kieun commented Jul 27, 2023

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.

@timcappalli
Copy link
Member

timcappalli commented Jul 27, 2023

The problem is that backup implies synchronization here.

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

The meaning of backup here is
...
Credential could be synchronized with some mechanisms

@Kieun it does not. See above.

I disagree with adding additional flags about sync.

@nadalin
Copy link
Contributor

nadalin commented Dec 20, 2023

@agl any update?

@nadalin nadalin assigned timcappalli and unassigned agl Dec 20, 2023
@timcappalli
Copy link
Member

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 BS flag to indicate whether the provider believes the credential is backed up and accessible to the user in the event of an authenticator/device change.

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.

@timcappalli timcappalli closed this as not planned Won't fix, can't repro, duplicate, stale Jan 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants
@agl @Firstyear @emlun @timcappalli @nadalin @Kieun and others