Credential Creation Options are inconsistent to Request
Closed this issue · 21 comments
In creation there is no way to specify to the user agent which transports we allow, since we only have:
https://www.w3.org/TR/webauthn-3/#dictdef-authenticatorselectioncriteria
https://www.w3.org/TR/webauthn-3/#enum-attachment
Which is limited to platform and cross-platform. This causes the situation to be confusing now with caBLE, where we may or may not want to allow this.
During assertion however, we can select this with:
https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialdescriptor
https://www.w3.org/TR/webauthn-3/#enum-transport
We should be able to specify allowed transports in registration, the same way we specify them in assertion.
I propose that we extend https://www.w3.org/TR/webauthn-3/#dictionary-authenticatorSelection with transports and we deprecate the use of authenticatorAttachment since transports is more expressive, and can express the full state and set of attachment modalities.
To clarify, you're suggesting that transports would be an array of them just like we can specify for public key descriptors?
If so I like it, it's a clever way to suggestion to fine-tune the use of WebAuthn in light of the new "cable" and how it's technically a cross-platform attachment 👍
This causes the situation to be confusing now with caBLE, where we may or may not want to allow this.
Could you elaborate on what it is you might want to allow or not allow?
Note that PublicKeyCredentialDescriptor.transports is
[...] a hint as to how the client might communicate with the managing authenticator [...]
So it doesn't set any restrictions on what transports may be used, it's only a hint the client can use to optimize user interaction. Most notably if all entries in allowCredentials specify "internal" as the only transport and none of those credentials are found in the platform authenticator, the client might simply tell the user that "this device is not registered" instead of prompting the user to connect a roaming authenticator. But the client might still allow the user to override that and try with a roaming authenticator anyway - it's not a hard restriction, just a hint.
I am not convinced that we should support filtering individual transports during registration. The distinction between platform and cross-platform credentials is significant because they enable different user interaction flows, but there's much less of a difference between USB and NFC for example.
As for caBLE, I expect that caBLE-enabled credentials will report their authenticatorAttachment as the current attachment mode for that particular registration or authentication operation (and clients decide in the same way for authenticator selection), but report their getTransports() as ["ble", "internal"] regardless of how they were attached during registration. That should resolve most of the ambiguity around those being both platform and cross-platform credentials depending on context.
With caBLE being cross-platform, RP should stop specifying "platform" and allow the User agents to optimize the UI.
I think allowing an RP to specify specific transports will create user frustration, and be counterproductive.
A really good example is that we may only want a specific vendor of usb authenticators to be used - then there is no need to display options for caBLE which in fact will confuse users "why can't I register my phone". (IE we have strict attestation and enforce it, so why not help guide the UI flow to prevent unrelated credentials being accidentally used).
As well, we have these options for authentication today, why are the not able to be consistent?
but report their getTransports() as ["ble", "internal"] regardless of how they were attached during registration. That should resolve most of the ambiguity around those being both platform and cross-platform credentials depending on context.
The issue here is you need to do a full registration cycle to getTransports() and then the RP can reject this, which will annoy the user more.
The authSel extension exists for limiting authenticator choice. But no user agent has implemented it, which would bode ill for other ways to try and do the same thing.
The transports in the assertion call are not to restrict authenticator choice, but to hint to the user agent about the capabilities of the authenticators that the user has already registered.
@agl Well there is currently a bit of a mess in the way the spec is setup. Both the RP needs to guide the user into which authenticator they may want to use for example, a passwordless flow, a password + security key, or some other flows we haven't thought of yet. And especially around attestation, we may know that we want a specific type of authenticator to be used. But then the browser has it's own authenticator guidance flows around this device, caBLE, usb keys.
So the confusion is who's job is it? Is it for the RP to hint to the browser what authenticators are valid so we can tune those work flows and policies of what the user agent displays to the user?
Or is it out of the RP's hands, and the user agent just does whatever the user wants and the RP has to respond (and potentially reject) registrations / assertions?
So why would it be different that an RP, especially in a corporate context may want to hint that "hey only usb devices are going to be accepted so don't ask for anything else"?
In an enterprise context, it's valid for the RP to have opinions about which authenticators are acceptable and there are (implemented) accommodations like enterprise attestation. But crafting those opinions in terms of transports isn't what RPs are asking for, at least not when they're asking me. Something like authSel, enabled only for RPs configured via enterprise policies, seems much closer to the mark. But that's about implementation, not spec, so it's something you have to bother the vendors about.
I don't really see anything in the spec today for enterprise authenticator selection so as far as I'm concerned as an RP developer for an enterprise, it doesn't exist. Can you link to where these features are available?
You are correct that enterprise authenticator selection doesn't exist in practice. But in the spec there's The authSel extension and (speaking for Chrome here) we get periodic requests for that in enterprise contexts. (Although it's certainly not the #1 request.)
If that's inadequate, then it would be reasonable to propose a different extension for this purpose.
Doesn't really help that nothing has implemented it then .... we already have a mechanism today for transport hints in assertion, why not expose the same in registration? It doesn't have to be policy, just a way to guide the user-agent to what they do / don't expose.
EDIT: We should amend the spec to indicate that this extension while defined isn't implemented ...
we already have a mechanism today for transport hints in assertion, why not expose the same in registration?
Because the transports are not intended for authenticator selection. This discussion about richer authenticator selection criteria seems like a duplicate of #1688.
We should amend the spec to indicate that this extension while defined isn't implemented ...
The Level 2 revision did this in a way by removing the extension, along with a few other unimplemented ones.
I feel like as a WG we've gotten into a hot mess with this situation ....
Given the lack of activity it seems like there's not much more to discuss here, so we're closing this. You're welcome to re-open the issue if there is more to discuss.
@emlun The issue isn't a lack of activity - it's still needed. It's a lack of interest from others in this wg.
The fact that transports is not consistent between registration and authentication is frankly silly.
If I at a company know that I only issue USB's for security keys, I should be able to direct the registration flow to ONLY use USB. Offering other options like caBLE causes user confusion.
Please re-open this.
We have given our reasons above for why there is a lack of interest in that use case.
Or is it out of the RP's hands, and the user agent just does whatever the user wants and the RP has to respond (and potentially reject) registrations / assertions?
Yes. The position of the WG is that users should be allowed to use their choice of authenticator for most RPs.
Even when it's impossible for those authenticators to work. Which will confuse and frustrate users. This is frustrating and silly that this position has been taken.
It's incredibly frustrating that with Chrome, a user can enroll an Android phone, but cannot use it to verify without "cable" in the list of transports, whose presence causes Safari to crash.
We absolutely need the ability to restrict registration the same way we restrict verification. At least until all the browsers comply with whatever standards are agreed upon.
It's incredibly frustrating that with Chrome, a user can enroll an Android phone, but cannot use it to verify without "cable" in the list of transports, whose presence causes Safari to crash.
We absolutely need the ability to restrict registration the same way we restrict verification. At least until all the browsers comply with whatever standards are agreed upon.
It might be just a stop-gap but given that transports are optional elements of the allowCredentials list, couldn't you just filter that out client-side before calling navgiator.credentials.get when you detect you are running on Safari?
It's incredibly frustrating that with Chrome, a user can enroll an Android phone, but cannot use it to verify without "cable" in the list of transports, whose presence causes Safari to crash.
We absolutely need the ability to restrict registration the same way we restrict verification. At least until all the browsers comply with whatever standards are agreed upon.It might be just a stop-gap but given that transports are optional elements of the allowCredentials list, couldn't you just filter that out client-side before calling
navgiator.credentials.getwhen you detect you are running on Safari?
The issue is registration, not authentication in this case.
At least until all the browsers comply with whatever standards are agreed upon.
I sympathize with your frustration, but the release cadence of these standards is very slow. By the time the transitional support feature is released in a mature standard, the incompatibility issues may just as likely have been resolved already.