Should we keep the word “passkey” in the spec or not

[ko-koiwai]

Background

The word “passkey” was added in PR #1901. In this PR, a passkey is defined as a synonym of a discoverable credential.
The reason behind this addition was to “add a specific definition in the context of the specification, that can be referenced throughout the specification whenever the term is use” as per #1901 (comment)
and to attempt “to codify the meaning of a passkey in the context of WebAuthn” as per #1901 (comment)

Issue

However, there were discussions around the definition of passkeys, some of them were:
#1901 (comment)

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

and as I pointed out in #1901 (comment),
Even within FIDO Alliance, some passkey definitions are inconsistently described:

• "A passkey is a discoverable FIDO credential" in FIDO (external) official FAQ at https://fidoalliance.org/passkeys/#faq
• "Any passworldess FIDO credential is a passkey" of the Passkey Messaging Guide, which is available at the top page of the FIDO Alliance members site.

Possible options suggested:

1. Leave the spec as it is (keep the passkey definition as a discoverable credential), and align the passkey definition within FIDO Alliance, or
2. Leave the spec as it is, and accept the difference between two standard organizations that jointly create FIDO2 specs, or
3. Remove the reference to the word "passkey" from the spec.

[timcappalli]

"A passkey is a discoverable FIDO credential" in FIDO (external) official FAQ at https://fidoalliance.org/passkeys/#faq

You answered the question. FIDO's public definition aligns with the definition in the WebAuthn L3 Editor's Draft. I see no justification for its removal (so option 1).

[MasterKale]

I believe @nicksteele's positively-received response towards the end of #1901 is the best rationale for keeping the definition of "passkey" in the spec:

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.

I strongly believe that developers who want to investigate the technical definition of what a "passkey" is won't go digging into the FIDO Alliance side of docs. Rather they'll come here directly to the WebAuthn spec or intuit things based on what they read on developer-centric sites like MDN or https://passkeys.dev who distill our work into actionable developer-centric insights.

The cat's out of the bag, and not offering an authoritative definition of what "passkey" is in the context of WebAuthn will ultimately harm WebAuthn adoption. The FIDO Alliance does important work, no doubt, but when it comes to websites it's the W3C and its specs that have outweighed impact on those who are the ultimate consumers of the WAWG and its outputs.

Therefore I think it is our prerogative to include a definition for passkeys, and so I support Option 1.

[MasterKale]

And to reiterate, adding the "passkey" alias to "discoverable credentials" allows us to offer nicer developer experiences in APIs like isPasskeyPlatformAuthenticatorAvailable() (#1901), soon to be replaced by the highly-demanded getClientCapabilities() (#1923). Methods like these offer developers memorable method names and return values to streamline things for developers, which ultimately raise adoption rates.

[maxhata]

We should discuss this with and as FIDO Alliance before it is resolved here, since both organizations have strong interests as the definition has a huge impact on marketing "passkeys".

[nov]

If it's a technical term, define it in technical document.
If it's a marketing term, its definition would be keep being fuzzy.
If it's a general term, no one can define official definition.

What kind of term "passkey" is?

[timcappalli]

We should discuss this with and as FIDO Alliance before it is resolved here, since both organizations have strong interests as the definition has a huge impact on marketing "passkeys".

It has been discussed in/with FIDO, ad nauseam, and as stated earlier, matches FIDO's public documentation.

[timcappalli]

What kind of term "passkey" is?

It is a noun, like password, which is used throughout related specs.

[nov]

OK, then there shouldn't be any official definitions.
Any document / organization / service can define it within the scope of it, and we as community just accept / reject them.

[timcappalli]

Any document / organization / service can define it within the scope of it,

The reference in the WebAuthn specification is for use by methods and text defined in WebAuthn. No one who worked on these WebAuthn changes has ever claimed otherwise.

Closing issue.

[maxhata]

I do not think this is complete and you should not close it.

[timcappalli]

Forgot there was a WG meeting today! Will leave open for that call.

[james-d-elliott]

I am a maintainer of a fairly popular RP library. While this is not in the browser space my perspective is from that of being an implementer.

I think having the terminology relevant to the consumer in the spec intended for the implementer is actually really important. It's especially really important to have it in there and explain the relationship between the consumer explainer technology and the technical technology.

My rational is that while finding this information is possible it's fairly difficult to do accurately. Having this in the spec makes it crystal clear when someone asks for "passkey support" (which I believe is going to be inevitable for many implementers) what that actually means in relation to the specific elements they have spent time to understand.

[nicksteele]

This was discussed on the August 9th WebAuthn Working Group call, the meeting minutes can be found here. The consensus of the working group on the call was that this issue should be closed with @timcappalli and @MasterKale merging #1936 into #1923 which will reference the term passkey.