Provide an explicit way to opt out of multi-device syncing/backups

[lxgr]

Sorry in advance if I missed the most recent state of the discussion on multi-device credentials, but if I understand the current proposals correctly,

• This property will be indicated as part of authenticator data (Backup state of credentials #1692, backup states in authenticator data #1695),
• There will be an opportunity to additionally create per-device "linked/bound" keys (Device-bound key extension #1658), but
• There won't be an explicit way for an RP to indicate that it wants to opt out of backups/multi-device syncing.

There might be a roundabout way to accomplish this (e.g. through always requesting a device-bound key per #1658), but am I understanding it correctly that there will be no "easy" way to do so, other than effectively only relying on device-bound keys and ignoring/discarding the "actual" key?

Is this intentional? At least for some scenarios, account takeover/phishing might be a large enough concern that RPs might decide to not accept certain (probably mostly host-based) authenticator models' attestation keys anymore for their service, even though they might otherwise be satisfied with the authenticator's security policies and implementation.

[serianox]

Hi @lxgr,

Yes, your understanding of multi-device credentials is correct. RP that do care about veting device syncing can currently opt-out with device attestation.

There won't be an explicit way for an RP to indicate that it wants to opt out of backups/multi-device syncing.

Since this is not UX friendly, because the error happen after te registration, I assume that we will soon add another preference selector for registration to specifically request devices without syncing, or an option to generate a key that will never be synced.

[ve7jtb]

I believe that so far the WG has rejected all proposals to have a relying party opt out signal of multi-device credentials.

The RP needs to make a decision if their account recovery is stronger than sending a password reset email to the person's apple or google account, then they can perform some sort of stepup to be able to accept the credential if the authenticator is unknown (there is still an open question, if platform authenticators will provide attestations) or the credential is multi-device.

The RP can cookie the browser and take that plus the multi-device credential to authenticate from the same browser, or if the cookie is not available due to it being a new device they can perform stepup.(Authenticate with a password, phone call, or roaming single device authenticator.)

I think the idea is that RP should not reject multi-device credentials, but can use a cookie, DPK extension(when available) or other factors to step up the authentication to the appropriate level.

It will be more work for some relying parties, I agree. This is pushing them towards taking a risk-based approach.

[lxgr]

This might unfortunately disqualify the use of platform authenticators in areas where two-factor authentication is explicitly mandated by a regulator, e.g. the EEA in the domain of secure cardholder authentication. A risk decision such as this:

The RP needs to make a decision if their account recovery is stronger than sending a password reset email to the person's apple or google account

is explicitly prohibited by law in some scenarios there (and password reset emails are not an allowable alternative).

The RP can cookie the browser

Do we really want to encourage the use of cookies as a form of device binding? If anything, RPs should be using DPKs for that use case, right?

On a related note, as a WebAuthN user, I explicitly don't want some of my credentials to be synced to my keychain under any circumstances (in particular the ones relating to financial transaction authorizations). Maybe there should be a parallel discussion around whether users should be provided with a way to opt out of key backups/syncing on a per-key basis? This is a different concern than the one of RPs opting out, though.

[timcappalli]

@ve7jtb

The RP needs to make a decision if their account recovery is stronger than sending a password reset email to the person's apple or google account, then they can perform some sort of stepup to be able to accept the credential if the authenticator is unknown (there is still an open question, if platform authenticators will provide attestations) or the credential is multi-device.

It should not be assumed that simply using a reset email for a platform account will grant access to multi-device credentials.

@lxgr

On a related note, as a WebAuthN user, I explicitly don't want some of my credentials to be synced to my keychain under any circumstances (in particular the ones relating to financial transaction authorizations). Maybe there should be a parallel discussion around whether users should be provided with a way to opt out of key backups/syncing on a per-key basis? This is a different concern than the one of RPs opting out, though.

This is an implementation discussion and would not be part of the WebAuthn specification.

[lxgr]

It should not be assumed that simply using a reset email for a platform account will grant access to multi-device credentials.

I read @ve7jtb's comment as implying that multi-device credentials only have to be better than the most common flow of email access recovery, not as a way of resetting access to an authenticator platform account holding multi-device credentials, but I even disagree on that point:

While this is arguably the most common scenario, as it is, many of the existing platform and roaming authenticators provide security guarantees significantly exceeding that. This is something that can enable new use cases, e.g. Secure Payment Confirmation.

It doesn't seem wise to implicitly roll these security properties back, in the interest of usability, without at least offering a way for RPs to opt out of it. (I do understand that making multi-device credentials opt-in, rather than opt-out, could hurt adoption.)

This is an implementation discussion and would not be part of the WebAuthn specification.

Got it, thank you @timcappalli ! So if this isn't something the WebAuthN specification would cover, is there any adjacent specification, or is it completely up to implementors?

[timcappalli]

Got it, thank you @timcappalli ! So if this isn't something the WebAuthN specification would cover, is there any adjacent specification, or is it completely up to implementors?

No, it is an authenticator implementation decision.

[ve7jtb]

I was making the point that unless the RP is doing something better than email password reset now they have no reason to reject multi-device credentials.

It may be that depending on implementation they may be significantly more secure, but I think we can agree that they won't be any less secure.

We should concentrate on how to uplift multi-device credentials if required and not focus on rejecting them.

My comment about cookies is out of practicality. More RP are going to be able to do that than reimplement their servers to support DPK.

DPK is a better option when available, but there is no guarantee that it will be available on all authenticators.

Cookies are sort of low tech but work today as a way to know if the device/browser has previously authenticated with a given credentialID. RP who are concerned should probably start there.

I don't know how financial institutions are going to deal with the change. perhaps on Android they will only create non discoverable credentials to get around syncing, though that is not part of the spec, and will not work with the updated non modal UX.

It is probably best for them to plan to use DPK as a signal when they can in SPC.

[lxgr]

unless the RP is doing something better than email password reset now they have no reason to reject multi-device credentials.

Every financial institution in the EU is doing something better than email password resets, as is required by regulations.

We should concentrate on how to uplift multi-device credentials if required and not focus on rejecting them.

Rejecting multi-device credentials will be possible, either via #1692 or more generally via requiring attestation and blocking all implementations known to sync.

The suggestion here is to offer RPs an option to indicate a preference for (not) syncing. This would allow implementations to invoke alternative behavior without requiring user intervention (for implementations that make sync capability a user choice via opt-in or opt-out, per credential or globally).

[serianox]

The suggestion here is to offer RPs an option to indicate a preference for (not) syncing. This would allow implementations to invoke alternative behavior without requiring user intervention (for implementations that make sync capability a user choice via opt-in or opt-out, per credential or globally).

As mentioned, some institutions are required by regulations to properly implement identity proofing. This extends to account recovery, and device syncing.

Those institutions will either:

• manually vet each vendor's implementation of device syncing, and accept them if they follow the required regulations,
• or reject any device sync mechanism that do not meet regulations, or all because they don't want to invest too much time.

My guess is that the implementation considerations that will be provided will be to either:

• go to a locked ecosystem where each vendor is vetted individually,
• or go to an open ecosystem where every sufficiently certified device is allowed, and DPK is always requested to trigger an explicit device sync flow: either reject the attempt because a new device is detected, or trigger the explicit enrolment of the new device through its DPK.

[lxgr]

or go to an open ecosystem where every sufficiently certified device is allowed, and DPK is always requested to trigger an explicit device sync flow: either reject the attempt because a new device is detected, or trigger the explicit enrolment of the new device through its DPK.

This would indeed be a way to enforce the current, non-syncing behavior if I understand it correctly.

Given that DPK is accepted as proposed, this proposal is then mostly syntactic sugar on the RP/API consumer side.

On the implementor side, it still seems useful to have, e.g. for UX purposes (as there is no point in uploading and showing a credential in a user's syncing account and downloading it to their other devices, if it can effectively never be used anyway).

[timcappalli]

The DPK is a device-bound key for use with the multi-device credential as a device signal for risk assessment. It does not replace the multi-device credential.

[lxgr]

The DPK is a device-bound key for use with the multi-device credential as a device signal for risk assessment. It does not replace the multi-device credential.

RPs are free to ignore it and only use the DPK for all authentication decisions (and out-of-band mechanisms for new device registration) though, right?

Effectively, this would be a complicated and (for implementations) intransparent way of opting out of syncing.

[timcappalli]

RPs can do anything they choose. That is not the intended usage though and wouldn't be covered in the specification.

[lxgr]

I understand that it might not be the intended usage, but I'm hoping to raise some awareness that it still might become a somewhat common pattern due to the regulatory and risk constraints outlined above.

If that assumption holds true, migrating from implicit to explicit RP behavior (where implementations would be receiving the "we will never use the synced credential" signal) might be hard or impossible.

[timcappalli]

I'd recommend discussing in the WebAuthn Community Adoption Group.