Meeting minutes
Credential Manager Trust Group (CMTG) Key
[Arnar introduces himself and presents slides]
Credential Manager Trust Group (CMTG) Key Explainer
Arnar: This is a WebAuthn extension
Arnar: We've been discussing trust signals for passkeys in FIDO.
… passkeys are generally synched, and so there have been discussions about how to get back some of the 'properties of security keys'
Arnar: Some threat model questions: What if sync fabric is compromised? What if password managers are malicious? What about use cases where sync is required? Those scenarios are out of scope.
… but there is an in scope threat for this discussion: what if the place you get the passkey from is phishable?
Arnar: So we are interested in addressing phishability of password manager.
Arnar: The goal is to signal when the passkey manager takes steps to protect against phishing
… there are some limitations (e.g., can't require unphishable login every time)
… proved absence of a pusher is not a property of one sign-in
… it is nearly impossible for a password manager to convey the "goodness of a device" and what constitutes "good" is very RP-specific.
… there are no good ways to attest on large platforms what software an attestation is coming from
… so our project is not to convey "the trust of a device"
… the project is, instead, to tell a relying party when one session is "unphishably related" to another.
… a password manager can tell an RP that a device is related to a device that has been accessed in an unphishable manner
… at .create() or .get(), an extra public key CMTGK is returned in the result.
… it will be used to sign the same challenge
[Arnar shows example of how devices become part of a trust group, represented by a trust group key]
Arnar: Trust groups can grow over time (even when device originally part of a different trust group)
Arnar: Password managers make sure devices only have the keys they are supposed to have
[Arnar talks about what admissible signals are to become part of a trust group]
Arnar: This is deliberately not defined in a W3C proposal. It is likely that FIDO will set guidelines.
Strawman:
- Provider verified proximity of devices
- provider used same strong physical factor on two devices (e.g., security key)
- provider verified strong phishing resistant external factor (e.g., phone number)
Arnar: CTAP/Hybrid can be used for proximity signal
… OS's offer other ways as well
Arnar: There are phone number verification mechanisms other than OTP
John_Earnshaw: Can the "type of signal" be transmitted to the RP?
Arnar: Most likely not.
… the more you tell the website, the harder the privacy aspect.
… a second reason - people worry a lot about if you give a lot of control you will have a lot of inconsistent adoption at the scale of the web
John_Bradley: A way to think about this is that it raises the bar for the general community.
John_Bradley: Without attestation you are relying on good behavior of providcers.
… I should note that at the moment the general case in webAuthn will require the RP to always ask for attestation so it can know if it is a single device authenticator like windows hello, or a security key what will not be providing CMTG keys on authentication
… you need to know during registration that it was a single device credential so you know not to expect signals on authentication.
… I would say this is voluntary probabilistic protection, not deterministic
Arnar: Agree that this does not protect against malicious password providers
Tim: If a security requirement is met by default ecosystem, you need to provide special tools
Albert: How should we think about CMTG related to BBKs?
Arnar: I think they are complementary.
… the CMTG is bound to the provider
Ian: I think that CMTG could be used to say "I trust this device so I'll trust this new BBK"
Arnar: There's a class of RPs and use cases that need "device bound proof"
… but we also think there's a large class of RP (e.g., online services generally)
… and where the "new phone" scenario with trust key will likely not lead to step-up
Jean-Luc: I hear primary objective is to give RP a signal that a device belongs to a trust group.
… are there additional security requirements for passkey managers? That might give more signals about the device itself.
Arnar: a password manager can choose to not make itself available on some kinds of device (e.g., TVs)
Tim: We are thinking about ways to convey "basic compliance"
… e.g, spec compliance
… we've started those conversations
John_Bradley: The problem is that, depending on the passkey provider deployment model, they may not be able to tell whether it's their actual passkey provider they are synching to (e.g., due to browser extensions)
… you are basically getting a "best effort approach"
… but not an absolute guarantee
<ottomorac> naive question: Can the RP require device bound passkeys? Like I do not necessarily trust bitwarden to hold my passkeys so I would rather make sure this a hw bound type one.
Otto: Can an RP require non-synched passkeys?
Tim: You can ask for one but may not get one.
… you can't in practice ask for one.
Dan: Is password manager step-up per transaction?
Arnar: No, once per device.
JB: And all the passkeys on the device can get upgraded to a trust group in the same step-up
Chrome SPC support update
stephen_mcgruer: BBK feature detection landed in Chrome 148, which started to stable on 5.
… so by next Tuesday or Weds should be available to all users.
<stephen_mcgruer> https://
Roaming authenticators and SPC
Bjorn: One requirement is that SPC should follow the WebAuthn flow for identifying authenticators to be used.
… consistent CTAP PUAT should be supported
w3c/
ACTION: Bjorn to add requirements to issue 12 for future WG discussion
BBK questions and answers
w3c/
<ottomorac> sorry
<ottomorac> wrong group
John_Bradley: What about chrome custom tabs?
… "can't be used for web views" might be right answer, but maybe chrome custom tabs needs another reply
John: We should also say explicitly "chrome custom tabs"
… some of those things like custom tabs DO share cookies. So it's not impossible, but we should make sure that the policy is not misunderstood.
Ian: How does it work today?
Stephen: I suspect you will get the same bbk as the chrome app that is backing the custom tab.
… custom tabs are not part of an application that calls it.
… from a UX perspective, it's visual embedded, but it is fully isolated from the calling app (which is different from web view scenario)
stephen: A custom tab is an instance of an "installed browser program"
John_B: Apple has a thing similar to custom tab
Next call
21 May