Re: [webauthn] Provide transport information during registration.

@akshayku thank you for enumerating the cases that like.

Firstly, I think we're in agreement that passing the transports back to the RP during registration is necessary in order to address important use cases. However, I think your case 1 is too limited:

In your case 1, you consider an RP filtering credentials by transport in order to discover whether any could potentially be used by a user logging into a new platform. But the RP doesn't necessarily know whether the login is actually on a new platform, or whether it's the old platform with cookies cleared. Thus that decision is best deferred to the platform because only it can test whether a platform credential is locally available.

Next, the same pattern of the platform being able to act more intelligently when in possession of transport information about a credential repeats when considering not just platform _vs_ non-platform, but which transports are available. If the platform knows that a given credential is BLE-only, and it doesn't have a BLE adaptor, then there's no point bothering with it.

I believe the above argues for providing transport information for each credential when requesting an assertion. Thankfully, that's in the current spec ([here]( Additionally, since `internal` is now a valid transport type, this mechanism also subsumes the need to provide an attachment property when getting an assertion and so I believe that your suggested spec change there is already taken care of.


More generally with your classification, you've split RPs into those that only accept platform credentials and cross-platform ones. But I don't see why any such RPs should exist. I think Christiaan is correct here to emphasise the two overarching uses: blessing new machines (i.e. bootstrapping) and reauthentication.

The latter is currently embodied by re-prompting for a password before doing significant account actions, even when logged in. The goal is to ensure that it's still the correct person behind the keyboard and this implies a user-verifying authenticator.

Blessing new machines implies using an external authenticator, which could imply a cross-platform authenticator. But that's fuzzy because platform-attached authenticators can be exposed by the platform over BLE etc. (See caBLE.) So I don't believe any RP would choose to accept only platform or cross-platform authenticators.

But, while I'm missing something there, I think the important thing is to focus on where I think we agree: we need transports to be provided during registration, and credentials should be able to indicate their attachment when getting an assertion—which is already handled in the spec by including transports in [PublicKeyCredentialDescriptor](

GitHub Notification of comment by agl
Please view or discuss this issue at using your GitHub account

Received on Friday, 21 September 2018 21:19:18 UTC