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

> First, re "assessment of UX", the proposal is not suggesting that FIDO security keys are involved in the passkey operations that RPs themselves 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.

In fact, the proposal suggests nothing about what keys are using for the RPK. My comments re FIDO key usage was trying to extrapolate in between the lines of the original document, and possible methods to try and tie something to a trust root. 

> 
> 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.

Okay, so what if my pw manager accepts both security keys vs password + totp? What distinguishes the difference between those sessions?

And then how can my pw manager signal that in a trustworthy way that the RP can truly believe? 

> 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.

Again, I think there are still too many unknowns in this proposal - without knowing how an RP might validate these signals, where the RPK private key comes from, and what the expected UX is, it is nearly impossible to assess the merits of this proposal.

We are discussing a technical method to allow an RP to trust a remote passkey provider - we need to see how that works end to end to assert if this proposal is valid to establish trust in that passkey provider.

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

You could also think of it as "session attestation". Unlike a FIDO key where you have guaranteed hardware properties, in this case you need to make attestations about the individual passkey/password manager session that the user authenticated to. Those properties are changing session to session (and potentially even per-request). 

However, just like you mentioned wrt to pw managers today, trying to attest a browser extension or similar is very difficult/impossible. I think this proposal will fall into the same traps unless there are clear, demonstrated methods to build that session attestation/rpk in a way that is trustworthy to an RP. 

So again - I think there needs to be far more detail about the actual methods in which a trust chain may be built by a passkey manager, how an RP may trust this, and what the user experience will be given those different trust methods. 

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


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

Received on Monday, 13 October 2025 00:34:17 UTC