Re: [webauthn] Provide transport information during registration.

Let me go back to the fundamental reason why we introduced an attachment property into the spec at the first place: the whole idea was that RPs can indicate which _use case_ they're trying to solve for. Either bootstrapping = x-plat, or reauthentication = platform.

During Get things are a little different: here we don't want to bother user with UI that has no relevance to them. This would include things like giving the user an option to insert an external authentication when an RP knows for a fact that they only ever created "platform" credentials (and never got a platform credential back that was annotated with a x-platform transport), or, giving the user the option to use an authenticator which is simply not available on this platform (for example, registering a BLE token on one machine, and then trying to use it on a machine without BLE. No point in asking the user to present that token).

I also don't really have sympathy for an argument which says: "but v1 of the spec doesn't include transports during MakeCredential, so we now have to do some weird, subpar workaround". We called this omission out in the working group as soon as we discovered it, and it was decided that it'll mess up the whole standardization process if we want to force it into v1. For that reason, we were okay deferring it to level 2 (or, really, version 1.0.1 - it really should be an extremely fast-follow), but we will pretend like it was just always there. If I knew that we were going to have to handle this in some backwards compatible fashion I would have insisted that we fix this before pushing the spec out.

Alright, now with all of the disclaimers out of the way, let's delve in to the 5 use cases.

Use case 1: Agreed
Use case 2: I prefer option 1. It gives us more flexibility regarding making decisions around what actual transports the system supports _at this point in time_. As I said earlier, there's no point in showing a user a dialog to "insert their external security key" if we know the user only has an external NFC token, and the platform we're on doesn't support that specific transport.
Use case 3: Having the transport information works fine for this use case too, right? You'll just not have "internal" as any of your transports in the credentialIDs.

Use case 4 and 5: These are basically the same, use case: Essentially, what you're saying is that, since transports information is a property of the credentialID, if there are no credentialIDs, we can't optimize the UX. I agree. I think the generic UI we had in mind actually worked pretty well for both these cases. Here was my thinking:
When doing an empty allowList, the browser will render an account chooser. If there are any credentials _locally on the system_ which can satisfy the request, they will be pre-populated in the list (I can see no reason why, if there are credentials, that an RP would willingly want to exclude them). If there are no credentials, the user will see an empty account selector. In both cases there will be a message below that says: "Please insert a security key with credentials for this RP" (or something to that effect) and the account chooser will then be populated as this happens. Granted, you might have had more discussions with RPs around the feasbility of this option, and if you absolutely believe that this won't work (I think we'll still try it), I can see a case for introducing the "attachment" property here, but it would **simply** be for the case where an empty allowList is specified. Of course, I'd still have to talk with the rest of the Google team to get their input here... especially since we'll probably handle both "attachment" cases exactly the same in order to _motivate_ RPs to not support only one of these use cases.

Makes sense?
P.S. I don't know where we've settled on the emlun and agl discussion. I don't really have any input there.


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

Received on Friday, 14 September 2018 12:00:21 UTC