Add new isPasskeyPlatformAuthenticatorAvailable() method

[timcappalli]

The current developer guidance to relying parties for whether they can offer passkeys to users is to call isUVPAA() and isConditionalMediationAvailable(). One returns a boolean, the other a promise. This is already complex . This also doesn't tell the whole story. For example, in Chrome and Edge on Ubuntu, users can currently create a syncable passkey on another device such as a phone or tablet using Cross-Device Authentication (hybrid transport). There is no way for a relying party to know this today, and passkeys won't be offered to users. This is a similar case with smart displays and other devices such as kiosks.

This method is designed to be a very simple way for the majority of developers to detect whether they can offer passkeys to users.

For more advanced use cases, isUVPAA() remains available, and an upcoming PR will introduce a more advanced feature detection method for things like specific transports (e.g. is just hybrid available) and CTAP2 security keys with client PIN entry support.

This was originally proposed during the WebAuthn F2F in April 2023.

---

Preview | Diff

[ndpar]

People use word "passkey" with different meanings: from very specific "syncable discoverable credential with UV" to just a synonym of "FIDO2 credential". Introducing it into the technical spec will add more confusion down the road, I'm afraid. I like the idea of the proposed function, but the name should't have "passkey" in it. isPlatformBackupEligibleAuthenticatorAvailable() would be more precise.

[timcappalli]

isPlatformBackupEligibleAuthenticatorAvailable() would be more precise.

@ndpar that is not what the method is conveying. This PR contains a definition of passkeys, aliased to the existing definition of a discoverable credential.

[MasterKale]

I'm happy for "passkey" to simply be made equivalent in WebAuthn to a "discoverable credential". The sync-ability of discoverable credentials is neither here nor there for the spec, which simplifies things greatly.

Regarding method name, I think isPasskeyPlatformAuthenticatorAvailable() ("isPPAA" 🤔) is fine. It's still too long for my personal preference, but because it follows the "PlatformAuthenticatorAvailable" pattern we've got with isUVPAA (and I can't think of a more succinct name for a method like this) then I'd be willing to commit to this one as proposed.

isPlatformBackupEligibleAuthenticatorAvailable() would be more precise.

@ndpar that is not what the method is conveying. This PR contains a definition of passkeys, aliased to the existing definition of a discoverable credential.

@ndpar I think I have to agree with Tim on this one, there's of course nothing about a discoverable credential that would prevent one from being used in a hybrid auth flow if it wasn't synced, nor via local platform authenticator under the same conditions. Thus I too believe it's better to leave out the idea of backup eligibility from this method, since all it's trying to establish is a developer-friendly method of intuiting if the conditions are right for passkey auth to likely succeed.

And from the RP's perspective I like that this presents a simple initial feature check that the browser is in a position to do hybrid registration/auth (it's currently impossible, for example, for an RP to understand via JS that a hybrid auth attempt failed because the browser didn't have Bluetooth permissions at the OS level).

I might argue that I'd prefer the check for a client's hybrid prerequisites being satisfied to be a separate API method, then devs could simply chain the existing isUVPAA method with such a hybrid check method. But if we get such a capability to check for that as part of a more full-featured feature detection API somewhere down the line then I think I'd be fine with this method combining the two signals.

[ndpar]

You guys just proved my point that the word "passkey" is confusing :) It must be defined precisely if you want to use it in the technical documentation. And I'm afraid your definition will differ from what most people think when they hear word "passkey", so I would avoid introducing it to the spec, unless you are ready to promote and defend your definition across the board :)

[Firstyear]

isPlatformBackupEligibleAuthenticatorAvailable() would be more precise.

@ndpar that is not what the method is conveying. This PR contains a definition of passkeys, aliased to the existing definition of a discoverable credential.

ndpar is correct though - despite what the standards authors may desire, there are at least 4 different definitions of what a passkey is in use by vendors.

• Any possible webauthn credentials (cite https://freeipa.readthedocs.io/en/latest/designs/passkeys.html )
• A synchronised/roaming credentials (cite https://support.okta.com/help/s/article/Passkey-Management?language=en_US )
• A credential that has BE/BS=true - I can't find an obvious cite for this, android could fall into this category though in a way.
• And the passkeys are resident keys as I'm sure you're aware of.

As a result, I think it's not correct for us to use an ambiguous and murky marketing term in a specification.

[Firstyear]

Marking as needing changes due to passkey being ambiguous.

[timcappalli]

ndpar is correct though - despite what the standards authors may desire, there are at least 4 different definitions of what a passkey is in use by vendors.

We're not referring to external definitions from vendor websites. We're referring to the definition in the specification.

Not sure what you mean by marketing term. Is password also a marketing term? Because password is used throughout Credential Management, the parent spec to WebAuthn. You'll get different definitions of password from different vendor sites as well :)

[MasterKale]

You guys just proved my point that the word "passkey" is confusing :) It must be defined precisely if you want to use it in the technical documentation. And I'm afraid your definition will differ from what most people think when they hear word "passkey", so I would avoid introducing it to the spec, unless you are ready to promote and defend your definition across the board :)

But this diff is attempting to codify the meaning of a passkey in the context of WebAuthn: it's a Discoverable Credential. Nothing more nor less than what is currently included in L3. If "discoverable credential" is confusing then that means the spec needs clarification about what a discoverable credential is.

[Firstyear]

But this diff is attempting to codify the meaning of a passkey in the context of WebAuthn: it's a Discoverable Credential. Nothing more nor less than what is currently included in L3. If "discoverable credential" is confusing then that means the spec needs clarification about what a discoverable credential is.

The only definition that matters is what people are using in reality - and sadly as much as we can define it here as many times as we want, the cat is out of the bag. Passkeys are a vague term and I think it can't be undone at this point.

[timcappalli]

The only definition that matters is what people are using in reality - and sadly as much as we can define it here as many times as we want, the cat is out of the bag. Passkeys are a vague term and I think it can't be undone at this point.

Which is why we add a specific definition in the context of the specification, that can be referenced throughout the specification whenever the term is used. Part of this PR does just that, in support of the new method defined.

[Firstyear]

Which is why we add a specific definition in the context of the specification, that can be referenced throughout the specification whenever the term is used. Part of this PR does just that, in support of the new method defined.

I think what you're saying is "If we define it here, that will fix it, so everyone will use the term in the same consistent way".

I'm saying "People are already using the term in a non-consistent way, and they will never change that behaviour no matter how much we define it".

In fact, by trying to add the term "passkey" to the webauthn specification it may in fact make the situation worse as people will arrive at the specification with a preconceived notion of what a passkey is and that may lead to misinterpretation of the specification due to this.

I think it's inappropriate to add a marketing term into a specification retroactively when it's already being used in various inconsistent ways in the public.

That's all I have to say on the matter, I'll leave it to others to agree or disagree with this.

[ndpar]

If "discoverable credential" is confusing then that means the spec needs clarification about what a discoverable credential is.

"Discoverable credential" is not confusing and well understood today in both technical and not-quite-technical audience. Are we deprecating it and replacing with "passkey"? I remember how much time it took to re-educate people about resident key terminology :) It'll be even harder with "passkey" since the term is already overloaded.

[MasterKale]

Are we deprecating it and replacing with "passkey"?

Based on the contents of this PR I wouldn't say anyone is proposing this. I'd characterize adding "passkey" as an alias of "discoverable credential" as an enabler of nicer API design. If isPasskeyPlatformAuthenticatorAvailable() is unacceptable because it introduces "passkey" into the spec, then we're stuck entertaining laughably long method names like isDiscoverableCredentialPlatformAuthenticatorAvailable(). Have we learned nothing from isUVPAA? 😂

[Firstyear]

isDiscoverableCredentialPlatformAuthenticatorAvailable

Consistency and clarity is more important - at least this name for all it's verbosity is direct about exactly what is requested. Where as isPasskeyPlatformAuthenticatorAvailable could mean "any possible authenticator", "a synced credential", "a credential capable of backups" or "discoverable credentials".

[ko-koiwai]

Agree with @Firstyear. My understanding is that FIDO Alliance officially adopted that "passkey" is any form of FIDO credentials even including UAF U2F (pls ask your borad representatives). As FIDO2 is a joint effort of W3C and FIDO Alliance, it is not developer friendly to use the same word in different ways in two organizations.

[dagnelies]

@emlun thanks for pointing out the definition. I think adding it to the spec would be a good thing overall since it clarifies what it is and reduces confusion.

[Firstyear]

There is consensus in the FIDO Alliance. The agreed-upon definition there (see https://fidoalliance.org/passkeys/#faq) is that a passkey is a discoverable FIDO credential, without further qualification:

Given that there have been comments in this thread like #1901 (comment) it's hard to say that the FIDO alliance definition is being found and understood, especially going back to the fact that businesses are already deploying 'passkeys` using a variety of self-chosen definitions to what they are.

I'm extremely against passkey as a term being introduced to this specification.

[ko-koiwai]

There is consensus in the FIDO Alliance. The agreed-upon definition there (see https://fidoalliance.org/passkeys/#faq) is that a passkey is a discoverable FIDO credential, without further qualification:

Yes I know that but it has been communicated differently within FIDO internally. (Please refer to the email from FIDO secretary dated May 11, 2023 if you subscribe to FIDO members mailing list.)

[nicksteele]

Unfortunately the term passkey has already been introduced to the standard indirectly, because passkeys are a type of WebAuthn credential and it's weird to treat them like we're saying Voldemort's name. Passkeys have existed for over a year, they are a relatively understood concept amongst this community, and in my opinion, to avoid saying the word passkey would cause more confusion and hinder any greater understanding of it by the dev community at large. Trying to not say 'passkey' by replacing it with isUserVerifyingPlatformAuthenticatorOrHybridTransportAvailable is just going to be far and away more confusing and less helpful than calling isPasskeyAvailable

there are no less than 4 definitions of passkey

Well that's a great reason to say the definition here, in the standard, from which passkeys are based. To @emlun's point we don't even need to define it ourselves, just link or reiterate FIDO's definition. I'd be fine adding a note or normalizing the FIDO definition to coincide with spec terminology, but I'd also say we have the most authority outside of the FIDO alliance to say what a passkey is or isn't.

Passkeys are going to be the majority type of credential used with the WebAuthn API, to avoid the term because some other companies have already defined it incorrectly is cutting off the nose to spite the face.

Marked as changes requested, but no changes proposed.

[timcappalli]

2023-07-12 call: 5 approvals, no objections to merging

[maxhata]

I think the term "passkeys" have strong implication on marketing.
There is a clear gap between this definition of passkeys and that of the WebAuthn partner organization, FIDO Alliance.
This will create further confusion on the issue.
We need alignment.

[nadalin]

In the end the consensus of the WG determines what goes in the specification, I did not hear any objections here

[Firstyear]

In the end the consensus of the WG determines what goes in the specification, I did not hear any objections here

I objected.

[maxhata]

I would object, too.

[dagnelies]

I objected too.

[nadalin]

@maxhata @Firstyear @dagnelies all the comments are reviewed before the merge and all merges are done by consensus on the bi-weekly calls, there were no objections, each bi-weekly call has an agenda posted and we discuss the issues and pull requests listed, you are welcome to join the calls to further discuss. You are welcome to open a new issue and we can discuss on the next call. Since all merges are done on the calls the consensus is done there after review of GitHub comments.

[Firstyear]

@nadalin I can't attend due to timezones and my work schedule.

It shouldn't be the case that people who are members don't have their voices heard because we can't join a call.

[nadalin]

I didn't say the voices weren't heard they said the decision is made on the call this has been the case for the last 5 years since the WG started, We review everything for doing the merge. All voices are heard whether you're on the call or not as long as you're comments are in the issue or pull request. We try to accommodate everybody on the call times as you know it always doesn't work out. So as I indicated if you don't agree with a pull request that was merged open up a new issue we have reversed pull requests in the past.

[devsnek]

What does this function return if i have a normal yubikey plugged in? What if i have a yubikey but it isn't plugged in yet?

[arianvp]

False in either case. Is neither a platform authenticator or a hybrid transport.

Instead is a Cross-Platform Authenticator with nfc or usb transport

[devsnek]

So is this function trying to discourage people from using yubikeys? Is there some security issue with them? I'm very confused what the direction here is.

[MasterKale]

isPasskeyPlatformAuthenticatorAvailable() very specifically checks whether a platform authenticator capable of leveraging discoverable credentials is available, either locally or via the hybrid transport:

WebAuthn Relying Parties use this method to determine whether they can create a new passkey using a user-verifying platform authenticator or a hybrid authenticator.

https://w3c.github.io/webauthn/#sctn-isPasskeyPlatformAuthenticatorAvailable

@devsnek To your question...

What does this function return if i have a normal yubikey plugged in?

...isPasskeyPlatformAuthenticatorAvailable() returns the same thing that would be returned if no yubikey was plugged in. The presence of a non-hybrid roaming authenticator does not factor into this method's return value.

False in either case. Is neither a platform authenticator or a hybrid transport.

This is incorrect. If a user-verifying platform authenticator is available and/or hybrid auth is possible then the method would return true. Again, the presence (or lack) of a security key does not change the availability of the platform authenticator or ability to use the hybrid transport.

[timcappalli]

Hey all - this is a merged / closed PR and likely will not be monitored any further.

If you would like to propose changes to the spec, please either create a new issue or a new PR.

If you have questions, please use FIDO-DEV or the Passkeys Developer discussion.