Transportation hybrid
naetraga opened this issue · 3 comments
Description
FIDO announced to add hybrid as transport method see here and Safari under macOS already sends hybrid.
Use Case
Safari running on macOS sends already transportation hybrid.
Documentation
Thanks for logging an issue.
This will be added once webauthn level 3 is ratified, there is no obvious benefit to adding it before then as it's just a documentation related change; unless I'm missing something. Regardless of what transport the FIDO2 authenticator claims the credential was using we pass those values through, as per the specification directives for RP's.
the only thing maybe to mention is that safari (Version 16.1 (18614.2.9.1.12)) already sends this value.
here an example from local.
{"type":"public-key","id":"obJ9sXiZE7SIx4IHXh-j1xFvl9o","rawId":"obJ9sXiZE7SIx4IHXh-j1xFvl9o","authenticatorAttachment":"platform","response":{"clientDataJSON":"eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiVzh2VWRLRVpxQnYwNUZxdlR3b2RTRU9JTGx3VVRpVmdicVVjZGdxOEJSVSIsIm9yaWdpbiI6Imh0dHA6Ly9sb2NhbGhvc3Q6MTU5MzAifQ","attestationObject":"o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViYSZYN5YgOjGh0NBcPZHZgW4_krrmihjLHmVzzuoMdl2NdAAAAAAAAAAAAAAAAAAAAAAAAAAAAFKGyfbF4mRO0iMeCB14fo9cRb5fapQECAyYgASFYILAdQk8LaqDHO3xD5I_ydh0g-etuy3tWYYdATerMcfNzIlgg4Xib-HRYnLCN69xk8jOo2rh848A3dYuvkampc0iQbkQ","transports":["internal","hybrid"]},"clientExtensionResults":{"credProps":{"rk":true}}}
As previously mentioned this does not cause the library to discard it. This is per the following specification areas:
A sequence of zero or more unique [DOMString](https://heycam.github.io/webidl/#idl-DOMString)s, in lexicographical order, that the authenticator is believed to support. The values SHOULD be members of [AuthenticatorTransport](https://www.w3.org/TR/webauthn-2/#enumdef-authenticatortransport), but [client platforms](https://www.w3.org/TR/webauthn-2/#client-platform) MUST ignore unknown values.
[[transports]]
This [internal slot](https://tc39.github.io/ecma262/#sec-object-internal-methods-and-internal-slots) contains a sequence of zero or more unique [DOMString](https://heycam.github.io/webidl/#idl-DOMString)s in lexicographical order. These values are the transports that the [authenticator](https://www.w3.org/TR/webauthn-2/#authenticator) is believed to support, or an empty sequence if the information is unavailable. The values SHOULD be members of [AuthenticatorTransport](https://www.w3.org/TR/webauthn-2/#enumdef-authenticatortransport) but [Relying Parties](https://www.w3.org/TR/webauthn-2/#relying-party) MUST ignore unknown values.
It is RECOMMENDED to also:
Associate the [credentialId](https://www.w3.org/TR/webauthn-2/#credentialid) with the transport hints returned by calling credential.[response](https://www.w3.org/TR/webauthn-2/#dom-publickeycredential-response).[getTransports()](https://www.w3.org/TR/webauthn-2/#dom-authenticatorattestationresponse-gettransports). This value SHOULD NOT be modified before or after storing it. It is RECOMMENDED to use this value to populate the [transports](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialdescriptor-transports) of the [allowCredentials](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialrequestoptions-allowcredentials) option in future [get()](https://w3c.github.io/webappsec-credential-management/#dom-credentialscontainer-get) calls to help the [client](https://www.w3.org/TR/webauthn-2/#client) know how to find a suitable [authenticator](https://www.w3.org/TR/webauthn-2/#authenticator).
See the subtest of TestParseCredentialCreationResponse named Successful Credential Request Parsing:
https://github.com/go-webauthn/webauthn/blob/master/protocol/credential_test.go#L34-L94
Even if an authenticator attachment of fake which does not exist is provided, this library honors and allows implementer to store this value.
See also the issue you linked:
Also, RPs only store and regurgitate these strings so no change
in RP processing is needed. Still, it's useful to have these strings
documented.