Re: [webauthn] Add Relationship Public Key (RPK) (#2338)

There's a couple of things worth clarifying here.

First, re "assessment of UX", the proposal is not suggesting that FIDO security keys are involved in the passkey operations themselves that RPs perform, neither for create nor get. There is no impact to the user ceremony or user experience. The only effect on UX is secondary, which is that this may allow RPs to spare users from other step-up auth such as SMS/email OTPs that they would otherwise be doing today.

Security key is mentioned only as an example of how the password manager itself may apply phishing protections to its own sign-in, which forms the basis for how it syncs RPKs around.

Second, re "we already have a solution", we do not have attestation of password managers and I believe we will not have meaningful attestation for another 5+ years. While we have the spec options and formats for it, a large fraction of users rely on platforms that cannot provide statements about the integrity/authenticity of client software. For one, many password managers are browser extensions which cannot be attested, and moreover on many desktop platforms there are no facilities for attesting running software (e.g. it can be affected by preloaded libraries, etc.). Note that attestation cannot only limit itself to how the private key is stored, it must also address how signatures are issued, e.g. whether RP-ID binding is correctly handled and if/how UV and other options in the request are handled.

Even if password manager client software could be attested or authenticated, for the password manager to say anything about the trust or integrity of the device itself, they would effectively have to become anti-virus software, which is well outside their current scope. 

> However, this is precisely what the proposal is - a method to assert trustworthiness of the remote passkey store. Phishing resistance is one aspect of trustworthiness when it comes to a private key store, as is use of a secure enclave and other requirements.

Re this, and "the process of trusting a relationship public key": This proposal comes about because I think we've fully exhausted the viable options for passkey providers and platforms to somehow vet the other parts of the trustworthiness story. But phishing remains of major interest to RPs, and hence this proposes to do something about just that part. RPs will still have to evaluate the trustworthiness of the device itself in some way that suits them, whether it is with step-up auth or other more silent signals. RPKs only allow them to transfer that trust evaluation between devices, given that many passkey providers will be taking good care of their own logins.

I like your term "neighbor attestation", that describes this pretty well - it's just not limited to FIDO security keys.

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


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

Received on Friday, 10 October 2025 16:16:31 UTC