CTAP intersection with CXP

[BryanJacobs]

Summary

CXP provides a way for two cloud providers to talk to one another about FIDO credentials.

How does a FIDO platform (ie, software on a desktop computer) talk to a FIDO authenticator (ie, a smartcard) to request an export?

Where is the CTAP component of credential exchange described / being drafted?

Details

I maintain an open-source implementation of CTAP2.1, and noticed CTAP2.2 has some kind of "digital credentials" extension in it but nothing related to CXP that I can find. Webauthn-3 has "backup eligible" flags etc but I'm unclear how that's intended to intersect with the authenticators themselves where said authenticators are not proprietary implementations from major players like Google or Apple.

Proposed Feature Type

Protocol

Proposed Feature Name

CTAP Credential Import/Export

Related Content

No response

[timcappalli]

Credential Exchange has no relationship to the Client to Authenticator Protocol. It also has nothing to do with "cloud providers".

CX* provides a way for two credential managers to exchange credentials and other autofill data for the primary purpose of credential manager migration.

[BryanJacobs]

Okay, so asking the question again: if I wish to exchange a credential that is currently on a hardware authenticator compliant with the FIDO standards (webauthn and CTAP) with another such authenticator, how do I do that? Which standard contains the way to get the credential OFF the authenticator?

[timcappalli]

No certified FIDO hardware authenticator allows a credential to leave its secure element, so what you're asking for does not exist, by design.

[BryanJacobs]

No certified FIDO hardware authenticator allows a credential to leave its secure element, so what you're asking for does not exist, by design.

Thanks for confirming. Just thought I'd double check I hadn't missed it.

Consider this a request, then: since the BE flag is present on credential creation (allowing RPs to choose if the credential should be shareable), the BS flag is asserted (allowing RPs to change trust levels depending on whether the credential IS shared), and the primary complaint about FIDO is how one handles backing up authenticators...

It would be nice if there were a way to create CEF files containing BS-bit-set credentials from on a CTAP-compliant authenticator, with the EXP and/or IMP being a FIDO authenticator vendor. (especially with the self mode)

I don't see any particular reason CEF is unsuitable, but the CXP importing provider rpId is unclear in that situation (what is the rpID for a hardware authenticator itself? Why is this called an rpId instead of some other name for a unique identifier, if as you say the protocol doesn't have anything to do with cloud services?).

[timcappalli]

Consider this a request

New features and capabilities are driven by ecosystem interest and needs. You're welcome to join the Alliance and work on the business case with other members. This is the first time I've heard this ask.

allowing RPs to choose

FIDO2/WebAuthn/Passkeys are a BYO key model. The RP has no control of this.

if the credential should be shareable

the BS flag is asserted (allowing RPs to change trust levels depending on whether the credential IS shared)

The BE and BS flags have nothing to do with credential sharing. They signal whether a passkey is a synced passkey or a device-bound passkey, and whether the authenticator believes that the credential is currently backed up.

what is the rpID for a hardware authenticator itself? Why is this called an rpId instead of some other name for a unique identifier, if as you say the protocol doesn't have anything to do with cloud services?

I don't understand this question. The RP ID is what the scope of the credential, and doesn't really have any direct relationship to the authenticator (other than the authenticator storing the passkey, which has a hash of the RP ID as part of it's metadata).

[BryanJacobs]

Consider this a request

New features and capabilities are driven by ecosystem interest and needs. You're welcome to join the Alliance and work on the business case with other members. This is the first time I've heard this ask.

I am legitimately surprised this hasn't been heard by all Alliance members already. At the bottom of the comment I have added links to a variety of Internet discourse over the last years about the lack of backup ability. I can't prove the lack of "how do I manage these sites that only allow me to enroll one authenticator" and "how do I let my wife access all my own accounts" is preventing people from adopting passkeys generally, but I certainly hear about it frequently. The list attached is very cursory and only a few examples.

allowing RPs to choose

FIDO2/WebAuthn/Passkeys are a BYO key model. The RP has no control of this.

You're making me doubt that I've understood the spec for webauthn-3 properly. I would appreciate a correction if I missed something. Here's my mental model:

• The Authenticator Data blob returned from a webauth-3 credentials.get call includes a flags member
• The flags member contains a bit to determine if the credential was allowed to be backed up (BE), and a second bit to determine if the credential was at some point backed up (BS)
• The RP receives the flags, and they can't be altered by the user agent / web browser as they're signed by the authenticator
• The webauthn-3 spec contains the language "If the Relying Party uses the credential’s backup eligibility to inform its user experience flows and/or policies, evaluate the BE bit of the flags in authData."

I take this to mean that the RP is allowed to reject credentials that are backup eligible, reject credentials that are backed up, or reject credentials that are NOT backup eligible. Right?

I also understand that the initial value of BE is set by the credential store in some way that works for password managers but doesn't work for hardware credentials (see: no protocol for passing the BE bit to hardware credentials over CTAP).

if the credential should be shareable

the BS flag is asserted (allowing RPs to change trust levels depending on whether the credential IS shared)

The BE and BS flags have nothing to do with credential sharing. They signal whether a passkey is a synced passkey or a device-bound passkey, and whether the authenticator believes that the credential is currently backed up.

Again I'm not sure I understood the spec properly here. Let's talk use cases. If I have a password manager containing a credential, when the cred is created it has BE=1,BS=0. If I sync that credential to another password manager, that same credential is now present in both places (to use my previous language, "shared"), and BE=1,BS=1 in both. Right?

For the purpose of this discussion please explicitly consider the case where one of the password managers involved is entirely under the control of the end user, and not a cloud services vendor.

what is the rpID for a hardware authenticator itself? Why is this called an rpId instead of some other name for a unique identifier, if as you say the protocol doesn't have anything to do with cloud services?

I don't understand this question. The RP ID is what the scope of the credential, and doesn't really have any direct relationship to the authenticator (other than the authenticator storing the passkey, which has a hash of the RP ID as part of it's metadata).

Quoting from https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html , section 3.2, "export request":

importer

    This member is the Relying Party Identifier of the Importing Provider.

I was speculating in this proposal that an Importing Provider could be a hardware key (or the vendor of a hardware key), rather than password manager software. Imagining for a moment that an Importing Provider is not a cloud-based password-manager application, what does "the Relying Party Identifier of the Importing Provider" mean? I feel like saying that the importer is a Relying Party Identifier is a sign that the specification was designed around the idea that both the importer and the exporter are web sites (as rpIds must be valid domain names). Thus my comment, that this might be better phrased than conflating the concept of a Relying Party with that of the importer's ID.

Summing up, I'm sorry that there isn't a way of using the standards here to let users have BOTH self-selected secure elements AND backups. I thought that was always the intent and the focus on cell phones and cloud password managers had just been an accident. I'm hopeful that the standard could still move in that direction, as one of the dozens - dozens! - of people who would prefer a smartcard over a cell phone for web site logins.

A few links as promised:
https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ , specifically criticising how "Under the FIDO2 spec, the passkey can never leave the security key" and lauding that "Passkeys can be stored and synced using the same mechanisms millions of people already use for passwords". Congrats on developing the spec that improves the situation for password managers, but...
Random Hackernews comments out of the dozens I see (searching Reddit finds the same):
https://news.ycombinator.com/item?id=31274677
https://news.ycombinator.com/item?id=34892820
https://news.ycombinator.com/item?id=33749525

[timcappalli]

I take this to mean that the RP is allowed to reject credentials that are backup eligible, reject credentials that are backed up, or reject credentials that are NOT backup eligible. Right?

Sure, an RP can do whatever they want with the response.

I also understand that the initial value of BE is set by the credential store in some way that works for password managers but doesn't work for hardware credentials (see: no protocol for passing the BE bit to hardware credentials over CTAP).

The credential manager / authenticator sets these bits, correct. Hardware security keys do not set either bit when creating device-bound passkeys (indicating the credential is not backup eligible, aka device-bound).

Again I'm not sure I understood the spec properly here. Let's talk use cases. If I have a password manager containing a credential, when the cred is created it has BE=1,BS=0. If I sync that credential to another password manager, that same credential is now present in both places (to use my previous language, "shared"), and BE=1,BS=1 in both. Right?

Yes, but in practice, credential managers set both to 1 when the credential is created. It is not intended to signify "sharing". It was created to provide RPs the ability to ask the user to remediate in the event a passkey was no longer synced (e.g. unlinking a device from a credential manager). Said differently, the BS bit isn't really used in practice today.

Imagining for a moment that an Importing Provider is not a cloud-based password-manager application, what does "the Relying Party Identifier of the Importing Provider" mean?

If it's a piece of software, a package name is a valid RP ID.

I'm hopeful that the standard could still move in that direction, as one of the dozens - dozens! - of people who would prefer a smartcard over a cell phone for web site logins.

This really has nothing to do with this stack of standards. Device-bound passkeys, by design, cannot leave the device on which they were created.