Re: [webauthn] Can we document protections (if any) around userHandle (with user-verification)? (#2266)

I appreciate the answers given here so far! I'm definitely understanding the nuances more. My apologies for taking up your time. I don't know of any resources (quite honestly, even the spec itself -- at least in a form a non-spec author can definitively parse) that accurately answer the types of questions I'm asking, so I didn't know anywhere else to go! I've **exhaustively** google'd and chatgpt'd my way along, but ... as you can see from my questions... I'm obviously not getting the full picture yet.

----

For clarity (and posterity sake), I want to broaden back out for more context:

1. I recognize the strong bias in the design of these features, and indeed the greater FIDO spec, for RPs to always be off-device (servers), and for them to manage solely the "identity" of a user in some system. Under these assumptions, they are the SoR, ostensibly, for the "user ID", and thus it makes sense to assume that if you knew the credential ID, you'd already know (or could get) the user ID.

2. However, I am actually coming from a different use-case and scenario, one where in fact the user ID would NOT be known at all *except* what's generated and stored in the user.id/userHandle field of a passkey credential in the client. I want the value in the userHandle field to be protected, and to ONLY come back in specific conditions.

    Thus, my questions are really all directly pointed here:

    - as a developer, under what specific circumstances, and with what degree of certainty and intentional control, may I be able know whether the passkey's userHandle field is going to be reported back when I assert with it? Both sides of the question are relevant: will it reliably come back? will it come back ONLY when I want it to, and not in other cases?

    - as a user of passkeys, is there any scenario -- not through hacking/compromising the device, but just normal usage of these available webauthn APIs -- where someone else could get my `userHandle` from the APIs? could they do so "silently" without any modal, browser/OS dialog, prompt, interaction, etc, regardless of how I set up the passkey? could they do so without me ever having given them "permission" to do so?

    - as a developer, is there anything I can do and control, in the **registering** of a passkey credential (including detecting that the authenticator should be rejected from use) to ensure that the userHandle in fact *does not* come back unless UV was used (i.e., that an authorized human has interacted to permit the action)?
    
        NOTE: this is distinct from the question of checking the response flag to see if UV was used or not.

3. My conception of "user verifying" is limited to devices/authenticators which return `true` from `PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()`. The MDN description of that method says:

    > A user-verifying platform authenticator is a kind of multi-factor authenticator that is part of the client device (it is generally not removable) and that involves an action from the user in order to identify them. Common user-verifying platform authenticators include:
    >
    > * Touch ID or Face ID (macOS and iOS)
    > * Windows Hello (Windows)
    > * Device unlock (fingerprint, face, PIN, etc.) on Android
    
    That seems to me to be narrowing the scope of devices/authenticators from a very broad range down to a more predictable set of behaviors and security guarantees. But I may be missing something here? Are there devices/authenticators where this `true` value is reported, indicating user-verification is *possible*, but that I may not be getting the same level of protection as I think I am?
    
    In particular, are my disclosed configurations to create() and get() -- shown earlier in this thread -- to say "I really want the highest security supported" just hints or theater, and there's in fact not going to be those protection guarantees out in the wild?

4. I of course am not able to exhaustively test on nearly as many devices/OS's as I'm sure implementers and spec authors here are able to do, so I imagine my experience seems rather limited and naive. However, I *have* tested on:

    - various "recent" windows (v10 and v11) devices (with Windows Hello enabled via the IR camera of the device)
    - various "recent" (last several years) macos devices, with e.g. Touch ID
    - various "recent" Android devices (tablets, phones), with Touch ID and/or Face ID
    - various iOS devices (some recent, some older), with TouchID and/or FaceID
    - safari exclusively on apple devices, but mostly chrome browser (and a little bit of FF) on the non-apple devices
    - in chrome, with or without the use of Google Password Manager (GPM)

5. From what I've observed in my various testing, the authenticators I'm accessing all seem to be enforcing a certain "security" around that userHandle field, protecting it by ensuring that it only comes back in UV cases (both in registration and in assertion).

    But is that just an illusion or accident, owing to the fact that there are many other types of biometric authenticators that I'm not testing on?
    
    Am I (OR NOT!?) *weeding out* the device/authenticator combinations and configurations that would offer a lower threshold of security/protection of the userHandle than I'm intending (as described in this thread)?



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


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

Received on Tuesday, 25 February 2025 16:48:14 UTC