Should an RP be able to provide finer grained authenticator filtering in attestation options?

[sbweeden]

The use case in mind is when an RP is required to enforce attestation-based registration requirements. Why not allow the RP to suggest in attestation options a richer set of acceptable authenticator properties?

An extreme here might be an AAGUID allow-list however there are other scenarios such as allowing an RP to express that it does not wish to leverage passkeys. If the RP is able to provide these types of constraints up front in attestation options it would permit a more streamlined client UX during registration flows.

[ve7jtb]

If a RP sent a flag to disable passkeys would the platform not make the credential on the platform authenticator if that authenticator only supported passkey credentials, and prompt the user to use an external authenticator?

We did add certifications to GetInfo In speculation of browser or RP policy eventually allowing for restricting creation FIPS 140 or something like that in regulated environments.

I can see providing a list as being useful in some situations, though it would likely add a fair bit of complexity if it is general purpose and may cause more people to shoot themselves in the foot.

I am interested in @agl ;s take on this.

[timcappalli]

If an RP does not wish to leverage platform passkeys, they can request a hardware-bound device public key using the extension.

[ve7jtb]

Shane and I have been talking with Max H in the consumer deployment working group.

I think he is looking for a simple way for RP to disable passkey without having to completely change all their existing webAuthn logic. That is I think partially where this request is coming from.

I suspect that @timcappalli is correct and any RP not wanting to accept passkey replication is going to have to do the work to redesign their backend to support that.

Keeping the default hardware-bound keys and making the RP do something to accept passkeys received a negative response at the plenary.

I understand that the desire is for the default to be what platforms consider to be the larger use case.

[timcappalli]

I think terminology and wording is important. An RP can't disable a certain credential export behavior. They can, however, request a second device-specific, hardware bound key, if they have a use case that requires this (and results in a degradation of user experience).

Another important note is that an existing platform credential does not automatically become a passkey on platform flag days.

[sbweeden]

They can, however, request a second device-specific, hardware bound key and ignore the passkey, if they have a use case that requires this (and results in a degradation of user experience).

Can you really "ignore the passkey"?

Shouldn't the RP during registration actually store both the passkey user credential, and the device-bound key, verifying the attestation of both, then on subsequent authentication flows request the device-bound key extension, verifying the authentication signature of the both the passkey public key and that in the extension, and make sure both the authenticating passkey credential is a property of the user's account, plus the credential in the extension is already associated with the user's passkey credential?

That's how I understood the requirements of the extension to work, which is actually quite complicated for RPs to implement.

As a related topic, what would happen if the credentialID of the device-bound credential observed in extension output during creation was used as a credentialID in the allowCredentials list of a subsequent authentication flow? I don't know of any currently defined behaviour for such a thing.

[ve7jtb]

@sbweeden that is how I understand it as well.

I believe there is only one credentialID with two public keys per device.

So if the user has three devices the RP stores one CredentialID and four related public keys.

One for the passkey and one for each of the devices.

It will be a major change for RP that want to keep using device bound credentials .

I am not necessarily arguing against this approach, but we need to be honest and realistic about the impact on enterprises and regulated entities.

My concern is those organisations will just ban all platform authenticator AAGUID for however many years it will take them to update the backends.

I will note that some organisations like SalesForce are just now migrating from U2F. Others like Bank of America have just rolled out WebAuthn. If we expect them to be able to deal with these changes by the time passkeys launch we need to start reaching out to them now. A spec may also be helpful.

[emlun]

[...] Why not allow the RP to suggest in attestation options a richer set of acceptable authenticator properties?

An extreme here might be an AAGUID allow-list [...]

This is precisely what the authnSel extension does. It was removed from L2 for lack of client implementations, but it still "exists" in the sense that it's there and "ready to go" if someone were to implement it.

Also it seems like I'm a bit out of the loop, what does "passkey" mean in this context?

[dwaite]

Also it seems like I'm a bit out of the loop, what does "passkey" mean in this context?

Someone correct me if they are using the term differently, but I expect a combination of:

1. Conditional UI through mediation, possibly used to make the UX appear closer to the "password manager form fill" experience
2. An authenticator which has credentials exported from the device to provide account-held credentials rather than device-held credentials. So far this appears to be more of a platform-proprietary synchronization feature than a general-purpose credential export.
3. Device-bound keys available an extension as more of a risk-system trigger - this is also being added as an alternative to behavioral selection for higher-assurance use cases (including the potential of those organizations rejecting some platform-issued credentials)

[timcappalli]

A passkey is a durable/survivable, FIDO2 discoverable credential (disclaimer: we're still tweaking the formal/official definition). The items @dwaite listed are features to support passkeys.

[agl]

A birdshot of thoughts:

While sites do not have assurance that a credential is device-bound today without checking the attestation, I accept that there is a norm that it will be, and that syncing credentials does perturb that. However, on the operating systems where Google provides a platform authenticator (i.e. Android and Chrome OS) our plan is that non-discoverable credentials will continue to be bound to the device as they always have been. Thus any RPs currently/planning to use non-discoverable credentials(*) are not disrupted.

(*) and those platforms don't support discoverable credentials yet().
() sorry; we know.

As noted above, sites that want to use passkeys and which feel that they can productively incorporate visibility about different devices into their risk calculations can use the device-bound key extension. This gives them the same device-bound properties as always, with additional information about who the sync provider believes the the user is. I hope that passkey support ships concurrently with support for that extension so that there's no gap. It is more work for the RPs to support, but it feels correct that sites with more complex needs deal with the more complex interface rather than the other way around.

About the authenticator selection extension itself: We have never implemented it because we don't feel that authenticator discrimination is broadly a good thing. Multiple different RPs might each have locally valid reasons for wanting to select the authenticators that are permitted on their site, but the sum of this is that users need to have multiple authenticators to span the set of different site policies that they encounter, they have to remember which goes with each site, and they can't have the expectation that a given security key will broadly work where they want to use it.

That argument isn't compelling in an enterprise setting where a company is distributing security keys for people to use specifically with their systems. Thus we wouldn't have a policy objection to supporting authenticator selection for RPs listed in an enterprise policy. But the feedback that we received was that depending on enterprise policy on the client was problematic. That's why enterprise attestation was incorporated in CTAP 2.1. It allows the policy to be contained on the security key itself and thus avoids this restriction. It's true that attestation is an after-the-fact rejection of a registration, but in an enterprise setting the enterprise is probably better equipped than the browser to communicate why a registration was rejected, and an enterprise always needs to check attestation if they want to require a specific authenticator because the client could ignore the authsel extension.

[equalsJeffH]

on 23-Feb-2022 call:
@sbweeden's position is that enterprise RPs wish to be able to establish their needs up-front when doing makeCred(), rather than after-the-fact (eg by examining resulting cred flags and/or attestation).
@ve7jtb seems that there would be a number of potential issues/special-cases in trying to broadly address this
@agl notes that giving RPs more tools to discriminate amongst authnrs will lead to situation we are trying to avoid where users have a plethora of authnrs and one or some work with one or some RPs.... though perhaps putting this sort of feature behind an "enterprise policy" is something to consider....