Re: [webauthn] Device-bound key extension (#1658)

There are three points of confusion I have with this proposal:

1. This feels like a "virtual" or "synced" authenticator having an extension to release additional attestated info at creation and assertion time of an underlying "physical" authenticator. As this would be used for cross-device flows with roaming authenticators, I feel "device" alone is confusing. I'm not proposing a bike shed discussion - I'm just commenting even as a placeholder name it does not really explain how this connects to any use case or fits within the overall system. 
2. There seem to be three different levels to the persistence of this device bound functionality:
    1. Logically at sync time a new public key is created, perhaps from a reproducibly computed private key, such that the same hardware authenticator will always return the same attested device public key for a given public key credential
    2. A device-specific public key is created if needed on use, with an indeterminate lifetime and various user and heuristic reasons it would be deleted. The attached device-bound public key can change at any time.
    3. The extension returns an attestation with no device key, attesting the local hardware but not creating a new public key
 
   I do not quite get the reasoning why the middle option was chosen vs the other two, and feel it would be really helpful if the reasoning could be captured/shared up-front. 

   For example, was the third option discounted because for compatibility the attestation would need to be computed for each authentication, and this is considered a computationally complex or online process for some formats? Or was it specifically to try to go "beyond" stock WebAuthn and have a cacheable/cryptographically-verifiable hint for risk analysis?

3. Given that the device public key as a persistence mechanism is defined to have an indeterminate lifetime, and given that this is only meant to represent a single device-level, attested authenticator, I do not understand "device" vs "app" context.  

   Is the expectation here that an "app" context and "device" context would have fundamentally different attestations, e.g. a bundle or application identifier embedded into the attestation for "app" contexts, thereby providing more information? Why then wouldn't the behavior be defined within the attestation format itself? A RP doing risk analysis would need to understand what these attestations mean and what information can be extracted.

  Conversely, would the attestation in an "app" context serve to group apps under a higher-level context such as the device or a an "app team"? If not, what is the app vs device context value meant to do in terms of RP processing or risk analysis? 

   Using "GitHub" as an example, it might have four different local app contexts (i.e. ssh, browser, native app, vs code). If the risk analysis is the same as if these had been four apps across different synced and bound platform authenticator contexts (laptop, tablet, phone, wearable), then I do not get the purpose of distinguishing the two.


-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1658#issuecomment-897489944 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 12 August 2021 09:32:11 UTC