Add Credential Manager Trust Group Key (CMTG) extension

[timcappalli]

Explainer: https://github.com/w3c/webauthn/wiki/Explainer:-Credential-Manager-Trust-Group-Key

[arnar]

Here's the explainer.

Edit: moved to Wiki

[Firstyear]

Having read the proposal I feel that there are too many vague elements in this proposal.

In the proposal, it states:

Why doesn't the credential manager simply attest to the device trustedness? Device trustworthiness is a complex issue, and we think it is outside the scope of passkey credential managers (and possibly FIDO2/WebAuthn in general) to define the criteria for this.

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.

Similar, this proposal will still need to rely on a way to assert trustworthiness of the relationship public key source. Effectively this has created "neighbour attestation" where you may not attest my password manager, but my password manager is proving it's trust via attesting my fido key was used to authenticate to it. There still must be some form of device trust built in this process, and that should be documented in this proposal so that it's whole value and user experience can be understood by the workgroup.

I don't believe it is clear what the user interaction would be with this extension. Would I use my password manager and during passkey creation/assertion also need to interact with my fido key to provide this trust relationship? In this case, what value did the password manager provide when I could have just directly authenticated with my fido key?

I think that this proposal is missing critical elements - the process of trusting a relationship public key, and an assessment of the user experience. Additionally, this seems to be a complex solution to a problem that we already have a solution for - if you need to assert the trustworthiness of a password manager, we have attestation for this.

[arnar]

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

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 synced keys cannot be stored in unexportable key storage, so the integrity of the password manager client software is really what matters. Attestation also 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.

And even if we could attest the password manager client software, that doesn't say anything about whether the current device is in the hands of an attacker or not. It has to include information about how the current device got signed in to the sync mechanism.

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 "neighbour attestation", that describes this pretty well - it's just not limited to FIDO security keys.

[Firstyear]

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.

[nsatragno]

I need to get this out of my system: CMTG sounds like a magic the gathering variant... maybe commander or something.

A credential manager that supports CMTG Keys will always return one if requested.

I don't think this should be the case:

• An implementation that exchanges information related to the (non) remoteness of devices with a server component may not be able to produce a CMTG key if the network is down (but can otherwise produce a WebAuthn credential).
• The UA may support CMTG, but perhaps the authenticator doesn't. I would prefer not to exclude those authenticators. CMTG should be seen as a "nice to have".

Unless there's a strong reason for this, we should allow a CMTG key to not be generated even if requested.

[arnar]

A credential manager that supports CMTG Keys will always return one if requested.

I don't think this should be the case:

• An implementation that exchanges information related to the (non) remoteness of devices with a server component may not be able to produce a CMTG key if the network is down (but can otherwise produce a WebAuthn credential).

That's a good point. I'm not sure returning no CMTG is the better course of action here rather than generate a new one though. Either way it seems the RP would behave the same, and the only implication is that if there is another sign-in before network to the provider is restored, then at least that second sign-in will carry some trust information and avoid e.g. another step-up.

• The UA may support CMTG, but perhaps the authenticator doesn't. I would prefer not to exclude those authenticators. CMTG should be seen as a "nice to have".

"Credential manager" generally means an authenticator, not UA, so that line does not suggest that they should be excluded. If the user selects an authenticator (either directly on create, or implicitly on get by selecting a credential) that doesn't support CMTG, then none would be returned regardless of UA support.

[nsatragno]

I went ahead and updated the explainer to

"A credential manager that supports CMTG Keys will usually return one if requested. If no CMTG private key exists for the selected passkey on the current device, the credential manager will usually create a new one. A credential manager may not return a CMTG Key if e.g. it relies on the network to do so, and the network is down."

Thanks Arnar!