- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Apr 2022 14:12:51 +0000
- To: public-webauthn@w3.org
> 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`](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialdescriptor-transports) is >[...] a hint as to how the [client](https://www.w3.org/TR/webauthn-3/#client) might communicate with the [managing authenticator](https://www.w3.org/TR/webauthn-3/#public-key-credential-source-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`](https://w3c.github.io/webauthn/#dom-publickeycredential-authenticatorattachment) as the current attachment mode for that particular registration or authentication operation (and clients decide in the same way for [authenticator selection](https://w3c.github.io/webauthn/#dom-authenticatorselectioncriteria-authenticatorattachment)), but report their [`getTransports()`](https://w3c.github.io/webauthn/#dom-authenticatorattestationresponse-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. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1716#issuecomment-1088756728 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 April 2022 14:12:53 UTC