Re: [webauthn] Provide transport information during registration.

@agl Let me try to explain the use cases

1. **With UserName Flow: User creates an platform credential on a mobile platform and want to use the same credential on other platforms.**
    - User tries to creates a platform/internal credential on one platform (Mobile). 
    - Platform creates the credential and tells RP all the transports supported by this credential (Lets say Internal, BLE, caBLE, NFC) in MakeCredential response. 
        - Whether we want to tell what transport was used is another question, but we are somewhat already telling this already in flags (2nd bit) for U2F authenticators.
    - User goes to another platform and types in his/her username
    - RP sees that the credentials created for the user can **_potentially_** be used over other transports in **_this platform_** and sends those credential list to the platform.
    - Platform can look for those credentials over other specified transports (NFC/BLE)

**_Spec changes required_**
- Supported transports needs to be passed back to the RP during MakeCredential

2. **With UserName Flow: User moving around between platforms and the RP only supports platform credentials**
    - User tries to create a platform/internal credential on a platform.
    - Platform creates the credential and tell the RP that the credential can only be used over internal transport as MakeCredential response.
    - User goes to another brand new machine and tries to login by entering the username.
    - RP sends all the known credentials for the user (which are all internal but platform may or may not have transports information as that is optional or not available in version 1 of the spec)
    - As Platform does not find any credential on this machine, with transports support, Platform can decide that this call in not going to succeed and tell the user about that and abort the operation.

**_Spec changes required_**
- Option 1: Supported transports needs to be passed back to the RP during MakeCredential 
OR
- Option 2: GetAssertion has a attachment property and RP sets that to "platform".

As we will have mixed authenticator credential registered between version 1 of the spec (which does not have MakeCredential transports response) and version 2 of the spec(which we are proposing), I would go for option 2 which works for all the cases.

3. **With UserName Flow: User moving around between platforms and the RP only supports cross-platform credentials**
    - User tries to create a cross-platform credential on a platform.
    - Platform creates the cross-platform credential and optionally tell the RP that the credential can only be used over internal transport as MakeCredential response.
    - User goes to another brand new machine and tries to login by entering the username.
    - RP sends all the known credentials for the user (which are all cross-platform but platform may or may not have transports information as that is optional or not available in version 1 of the spec)
    - If the transports information is available, platform only sees cross-platform credentials, Platform will not find any credential on this machine and can go directly to look for external authenticators. 

**_Spec changes required_**
- GetAssertion having an attachment property and RP sets that to "cross-platform". 
   - This gives flexibility to the platform to not even look at platform credentials and waste time/introduce unwarranted UIs. Then platform can directly go looking for external authenticators.

4. **Without UserName flow: User moving around between platforms. RP supports only platform credentials.** 
    - User goes to a machine and creates a platform credential.
    - User goes to another brand new machine and tries to login by clicking a link which kind of says "Login with platform or security keys". There is no username entry here. No cookies etc. 
    - As this is a brand new machine, there is no platform credential for this RP and platform does not know whether user wants to use platform credential or user has a roamable credential as this is username less flow. So platform has to go to look for external authenticators. 
    - Above step is very confusing for the user as he/she never had an external security keys. 
    - Adding a page which says no platform credentials are found and having a link which says go to external authenticators introduces a very bad friction for below use case. Having a link in itself where RP does not support about external devices is also not desired by the RPs as a feedback given to us.

**_Spec changes required_**
- GetAssertion has a attachment property and RP sets that to "platform".


5. **Without UserName flow: User moving around with external security keys. RP supports only cross-platform credentials.** 
    - User goes to a machine and creates a cross-platform credential.
    - User goes to another brand new machine and tries to login by clicking a link which kind of says "Login with platform or security keys". There is no username entry here. No cookies etc. 
    - As this is a brand new machine, there is no platform credential for this RP and platform does not know whether user wants to use platform credential or user has a roamable credential as this is username less flow. So platform has to go to look for external authenticators. 
    - Adding a page which says no platform credentials are found and having user clicking a link is a very bad user experience for a user/RP who only wants to deal with external security keys for any reason. For this reason, we are not introducing that page as it slows down the user login and that is not what user/RP wants and has given feedback to us.

**_Spec changes required_**
- GetAssertion has a attachment property and RP sets that to "cross-platform".


**_Summary_**
- Having a attachment property in GetAssertion is very important and absolutely required for various scenario especially with username less flows. It solves various ambiguous UI issues. We have already given flexibility of choosing platform vs cross-platform in MakeCredential 

- If we want to solve use case 1, then sending transports back to the RP is also required. For use case 2 of not showing external authenticators in **_identifiable platform only with username_** case, that can be solved better with attachment property in GetAssertion.


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

Received on Wednesday, 12 September 2018 19:53:02 UTC