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

Honestly, your posts are extremely lengthy and likely won't receive many responses. I don't have the time to go over every aspect of your questions, so I'll just provide a general response that will hopefully be enough.

1. You don't say what you plan to do with the sensitive user handle or what information it apparently will contain. Regardless of what browsers and authenticators do, WebAuthn [clearly states](https://w3c.github.io/webauthn/#sctn-user-handle-privacy) that user handles must not include personally identifying information and even states:

> Authentications MAY reveal user handles without first performing user verification.

Consequently, you must _not_ rely on a "secret" user handle; doing so is in violation of WebAuthn.

2. You use words like "guarantee". What do you mean by that? Guaranteed by the laws of physics is different than guaranteed under the assumption of a bug-free implementation of a "bug-free" specification. Fact is most specifications
are not written by mathematicians in some formal grammar that has been proven; thus you must have a somewhat "relaxed" expectation of the specification and even more relaxed expectation of an implementation of said spec since almost no software or hardware undergoes formal verification.

For example, nothing stops me from writing my own "browser" and having it do _anything_ I want. What stops one of your users from using this browser? What about a bug in \<insert browser here\> that does (or does not) do something it should? What about authenticators? What stops me from manufacturing my own USB-based authenticator? _Hopefully_ it conforms to [CTAP 2.2](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html), but what if it doesn't (e.g., I intentionally sabotaged it or just accidentally wrote a bug)?

Also note there may not even be a specification for certain authenticators; so while CTAP 2.2 _may_ be used for USB-based authenticators, it may not apply to other authenticators like FaceID-based ones.

The best you likely can do is have a hardcoded set of authenticators that you "trust", then use attestation during registration to enforce that only those specific authenticators are being used by your users. This set of authenticators is entirely on you to decide. You can contact the manufacturer of an authenticator and inquire what "guarantees" does the authenticator provide. You can hack up your own program that communicates with the authenticator attempting to get the authenticator to do something you don't want. Relying on popular browsers to do this communication is a nice first step, but it obviously
doesn't "prove" that the authenticator behaves the way you want.

Again, though, while the only entity that can tell you definitively about what "guarantees" an authenticator provides is the manufacturer; it's highly likely said "guarantees" are based on _intent_ and hopefully some level of validation; but it is _extremely_ unlikely the "guarantees" are based on actual formal verification.

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


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

Received on Thursday, 13 March 2025 18:28:06 UTC