Re: [webauthn] Include an AuthenticatorTransport when creating a new credential.

@akshayku 

> We have authenticators which support multiple transports.

As noted [above](https://github.com/w3c/webauthn/pull/882#issuecomment-385107649), this was intended to be a sequence but I've been slow in getting around to updating it. I'm hoping to do so before today's call.

> Relying on transport information during MakeCredential and making decisions based on that is not a good design.

This does not introduce any decisions based on the transport during MakeCredential. It's reporting the information that's currently in the FIDO attestation statement in a less weird place.

> I would not put "internal" enum in transports to fix the real issue.

We need a value for this irrespective because the current enumeration is insufficient. (See [here](https://github.com/w3c/webauthn/pull/882#issuecomment-385743344).)

> and boils down to not having attachment property in getAssertion.

This is a valid point of discussion. Christiaan believes that it'll be easier for RPs to copy the transports from the credential into the assertion response and he talks to a lot of them. I believe that reporting an [`AuthenticatorAttachment`](https://www.w3.org/TR/webauthn/#enumdef-authenticatorattachment) in addition to the transport and plumbing that into [`PublicKeyCredentialDescriptor`](https://www.w3.org/TR/webauthn/#dictdef-publickeycredentialdescriptor) is also a plausible answer, but I'll let Christiaan argue between them.

@equalsJeffH 

> …meaning that the transport in this case could be, e.g., USB, yes?

Depending on how the second desire pans out, a platform authenticator that happens to be attached via a USB bus could be recorded as either `usb` or `internal` (if we decide to have `AuthenticatorAttachment` hold the attachment), or must be `internal` (if we decide to use the transport to indicate attachment here).

Although, even in the former case, if this information is intended to guide RPs in their messaging and UI, an internal USB bus isn't “USB” as far as any user goes, so I'd still say that `internal` would be a more accurate answer.

> If so, perhaps we ought to provide guidance…

Yea, this change is too skinny at the moment, but I'll see how the discussion about using `internal` to indicate a platform authenticator pans out first. Thanks.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/882#issuecomment-386045167 using your GitHub account

Received on Wednesday, 2 May 2018 16:50:28 UTC