Add new isPasskeyPlatformAuthenticatorAvailable() method #1901
Conversation
timcappalli
changed the title
|
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. |
@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. |
|
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
@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. |
|
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 :) |
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.
As a result, I think it's not correct for us to use an ambiguous and murky marketing term in a specification. |
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 :) |
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. |
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. |
"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. |
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 |
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". |
|
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. |
|
@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. |
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. |
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.) |
|
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
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. |
timcappalli
dismissed
Firstyear’s stale review
Marked as changes requested, but no changes proposed.
|
2023-07-12 call: 5 approvals, no objections to merging |
SHA: 5bd3dd1 Reason: push, by timcappalli Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
I think the term "passkeys" have strong implication on marketing. |
|
In the end the consensus of the WG determines what goes in the specification, I did not hear any objections here |
I objected. |
|
I would object, too. |
|
I objected too. |
|
@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. |
|
@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. |
|
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. |
|
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? |
|
False in either case. Is neither a platform authenticator or a hybrid transport. Instead is a Cross-Platform Authenticator with nfc or usb transport |
|
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. |
|
https://w3c.github.io/webauthn/#sctn-isPasskeyPlatformAuthenticatorAvailable @devsnek To your question...
...
This is incorrect. If a user-verifying platform authenticator is available and/or hybrid auth is possible then the method would return |
|
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. |
The current developer guidance to relying parties for whether they can offer passkeys to users is to call
isUVPAA()andisConditionalMediationAvailable(). 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