Handling UP=false/UV=false from Apple's Automatic Passkey Upgrade during credential creation
Nico
Hi FIDO Developers,
We are in the process of implementing passkey support for our service and have encountered a specific scenario with Apple's "Automatic Passkey Upgrade" feature that we'd appreciate the community's insights on.
Context: Apple devices (iOS, macOS) running recent OS versions offer a feature where, after a user successfully logs in using a saved password via iCloud Keychain autofill, the system may offer to "upgrade" that password credential to a passkey. In some cases, particularly noted with more recent updates, this upgrade seems to happen automatically or "silently" in the background shortly after the successful password login.
Observation: When this automatic/silent upgrade occurs, our Relying Party (RP) backend receives a navigator.credentials.create() call result. However, upon inspecting the authenticatorData associated with the created credential, we consistently find that both the userPresence (UP) flag and the userVerified (UV) flag are set to false (0).
The Conflict with WebAuthn Expectations: Our understanding of the WebAuthn specification (L2/L3) and common RP best practices is that for a navigator.credentials.create() operation, User Presence is generally required (i.e., requireUserPresence defaults to true in authenticatorSelectionCriteria). RPs typically verify that the returned UP flag is true to ensure the user was actively involved in the creation ceremony. Consequently, our backend library (and likely many others strictly following the spec's intent for registration) rejects these credentials because the UP flag is false, failing the standard validation check.
We understand why UP might be false in this specific Apple flow – the create() call happens programmatically after a password login, potentially without a separate, explicit user interaction at the exact moment of passkey creation. However, the result conflicts with the standard RP security validation for new credential registration.
Questions for the Community:
- Shared Experience: Are other Relying Parties observing this same behavior (UP=false, UV=false) from Apple's Automatic Passkey Upgrade mechanism?
- Handling Strategy: How are other RPs dealing with this?
- Are you strictly enforcing UP=true for create() and therefore rejecting these automatic passkeys?
- Or have you implemented specific exceptions to allow these credentials? If so, how do you reliably detect this specific flow, and what are the security considerations?
- Apple's Guidance: Is there any official documentation or statement from Apple acknowledging this UP=false output for automatic upgrades and advising RPs on how to handle it?
- Specification vs. Implementation: What is the recommended course of action from a FIDO perspective? Should RPs deviate from the standard UP check for create() to accommodate this vendor-specific flow, or is adhering to the stricter interpretation preferred?
- Security Implications: What are the community's thoughts on the security assurance level of a passkey created automatically following a password login, where the create() ceremony itself returned UP=false?
We are trying to balance providing a smooth user experience (especially for Apple users encountering this feature) with maintaining robust security guarantees aligned with the WebAuthn specification. Any insights, experiences, or pointers to relevant discussions/documentation would be greatly appreciated.
Thanks
Tim Cappalli
>> Are you strictly enforcing UP=true for create() and therefore rejecting these automatic passkeys?
>> Or have you implemented specific exceptions to allow these credentials? If so, how do you reliably detect this specific flow, and what are the security considerations?
Kosuke Koiwai
actually a way to temporarily set UP=1 while you wait for the update
of your library.
Here’s a little experimental code that tweaks the attestation object
to force the UP flag on:
function forceUPflag(cred){
if(cred.response.attestationObject.startsWith("o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0")){
// when the first part of CBOR matches ("fmt":"none","attStmt":{},"authData")
const attObj = base64url.toBuffer(cred.response.attestationObject);
let view = new Uint8Array(attObj);
let flag = view[62];
flag = flag | 1; // UP flag is the least significant bit
view[62] = flag;
cred.response.attestationObject = base64url.encode(view);
}
return cred;
}
This tweak is really just for testing and not something I’d recommend
for production.
It works because the UP flag at registration isn’t actually signed by
the authenticator, so technically, browsers or extensions could mess
with it.
Most platform authenticators don’t provide attestation (they use
“none”), so the registration response is not signed and you can’t
really verify the registration response’s details.
That’s something to keep in mind when deciding how much to trust the
UP and UV flags, especially during registration.
Best,
> You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
> To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/886ea980-3a06-45f0-b605-b92fa8c46d1dn%40fidoalliance.org.
My1
Arshad Noor
You need to understand the premise of FIDO/WebAuthn, as was
originally envisioned by the FIDO Alliance's founders: to be a
"strong authentication", privacy-protecting protocol, mandating
high levels of security, but that could be made ubiquitous and
cost-effective through a global industry standard. While unstated
in the specification - but discussed within technical meetings -
the resulting authentication protocol had to be simpler, stronger
and provide a better UX than ISO-7816 smartcards with X.509
digital certificates (which provided the highest
security level of passwordless strong authentication as
early as in the late '90s - albeit at high cost)!
ALL of those objectives were met with the FIDO2/WebAuthn Level-1
specification.
The problem was, there was only one browser manufacturer
participating in the earliest incarnations of developing the
WebAuthn spec; another joined, but had significantly fewer
engineering resources. Obviously, the larger manufacturer was able
to drive many of the specifications and development of browser
features. Not knowing the intricate details behind browser
development, it was not easy for outsiders to understand the
different ways the UX evolved between the two browsers.
A little later, another browser manufacturer joined the
specification, and much, much later, the last major manufacturer -
the company you specifically referenced, Apple - eventually joined
the party. By now, significant investments were being made by the
FIDO ecosystem in the manufacture of FIDO Security Keys, FIDO
servers, FIDO-enabled browsers and UX designs by hundreds of
companies. RPs were even deploying applications into production.
One significant problem that bogged down discussions was around
Account Recovery - what happens when the user loses their one and
only Security Key or device with their FIDO credential? How do
they get back access to their account? Companies in the regulated
environment, and security-conscious people understood the risk
implications of trying to get the user back into their account if
no other strong authentication mechanism was available.
The simpler answer to this problem was obvious: given that adoption of FIDO was likely to be highest in richer countries of the OECD, educate users/companies to acquire/provision two Security Keys to register two FIDO credentials and use either one of them to authenticate to the RP site. FIDO is unique among authentication protocols in its ability to create and use multiple, unique credentials to authenticate to a single user account at the RP site*. Or, if two Security Keys were infeasible, use one Security Key, and within a session authenticated by that Security Key, use a device with a secure element (TPM) or a TEE, and register a second device bound FIDO credential where the private key never leaves the computing device. This allows RPs to choose authentication flows that manage their risk appropriately:
- If both Security Keys have cryptographic hardware secure elements, any operation is permissible;
- If one Security Key and the computing device have a hardware secure element, again, any operation is permissible;
- If the computing device only has a TEE, low/medium risk
operations are permissible, but for high-risk transactions, a
secure element-based credential is necessary
The question of whether UP being optional was never
discussed; UV was optional from the start - and the market
responded with different Security Keys to support those needs.
Platform computing devices and browsers evolved to supporting UP,
and prompts for PINs or biometric options for UP/UV.
Apple, in its earliest incarnations of adopting FIDO/WebAuthn
conformed to these specifications, signalling great promise for
the adoption of FIDO to the industry. Regrettably, on their own
volition, they chose to change
the game. Google and Microsoft, the other two platform
providers, chose not to be left out and jumped on the
"synchronized passkey" bandwagon.
And, so here we are now. The strongest authentication protocol
since TLS ClientAuth, has been turned upside down and all privacy
promises have been broken in synced passkeys. Even UP - a given,
whose optionality was never discussed - is dispensed with.
The fact that FIDO/WebAuthn Level-1 delivered device bound
private keys, transaction confirmation, Android Key
Attestation, and the investment of hundreds of companies in
the ecosystem were all tossed out, so Apple users never have to
worry about where their passkey is, is a reflection of market
power. What could have been solved with education, and the
negligible cost of an additional Security Key for first-world
consumers, was left at the wayside and we now have a confused
ecosystem, potentially
massive consolidation of private keys in the cloud, and
complete loss of privacy for consumers**.
Bottom line? At WebAuthn level-1/Level-2, the FIDO ecosystem was at a place that enabled RPs to do the things you are trying to do - and you can still do them! You can even go further than the basics if you want - all the way up to NIST AAL-3 - and with enterprise attestation, even beyond. But you have to understand the implications for your company, and the investments (policy, training, development, procurement, etc.) you have to make for the level of security you want.
The FIDO/WebAuthn capability was expected to establish a baseline
level of security and privacy that was higher than what
smartcards+digital certificates offered; it is now "balkanized"
and RPs are going to have to live with it.
Arshad Noor
StrongKey
* Technically, it was/is possible to issue end-entities (aka users, applications, devices, etc.) multiple digital certificates that enable passwordless TLS ClientAuth to the same account; given its attendant cost, RPs that deployed PKIs just chose not to do it.
** The irony of the situation is, that a colleague just recently
brought to my attention that Apple is requiring two (2) Security
Keys when registering FIDO credentials through macOS settings -
and it is not through their browser - see attached images.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/98a64458-82ee-4b62-b609-b1c2a4df98c4n%40fidoalliance.org.
Tim Cappalli
Enough with the FUD, Arshad. People come here with specific questions to help their deployment journey and shouldn’t be subject to your constant disgruntled rants and accusations.
It’s exhausting. Stop.
Respectfully,
tim
@nicol...@gmail.com, sorry you have to deal with this. passkeys.dev/discuss may be a more welcoming environment for deployment questions as you roll out passkeys.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/9af8e610-2ffc-41e3-ba0e-371c31bd556a%40strongkey.com.
Arshad Noor
If any of this is factually incorrect, please point that out - I do not
have a problem being corrected.
Secondly, having worked with passwordless strong authentication for 25+
years and deployed dozens of infrastructures - and still continue to do
so - I believe I have a reasonable understanding of the strong
authentication industry, where it came and where it is likely to go.
Opining about that arc with references and factual statements is not "FUD".
If any of my statements are a violation of the code of ethics and
conduct on this forum, please feel free to report it to the people who
have the authority to take action - I will deal with them. However, you
do not have the standing to shut down public discourse of an industry
standard protocol because you happen to disagree with certain aspects of it.
Otherwise, I believe it is still a free country, and you always have the
option of deleting any posting you want in your reader without reading
them - or by leaving the forum permanently if you choose to.
Arshad
P.S. And, please don't apologize for me; if I have been wrong, I don't
have a problem apologizing for myself.
On 4/20/25 9:37 AM, Tim Cappalli wrote:
> Enough with the FUD, Arshad. People come here with specific questions to
> help their deployment journey and shouldn’t be subject to your constant
> disgruntled rants and accusations.
>
> It’s exhausting. Stop.
>
> Respectfully,
>
> tim
>
> deal with this. passkeys.dev/discuss <https://passkeys.dev/discuss> may
> passkeys.
>
> *Date: *Sunday, April 20, 2025 at 12:12
> *To: *fido...@fidoalliance.org <fido...@fidoalliance.org>,
> nicol...@gmail.com <nicol...@gmail.com>
> *Subject: *Re: [FIDO-DEV] Handling UP=false/UV=false from Apple's
>
> You need to understand the premise of FIDO/WebAuthn, as was originally
> envisioned by the FIDO Alliance's founders: to be a "strong
> authentication", privacy-protecting protocol, mandating high levels of
> security, but that could be made ubiquitous and cost-effective through a
> global industry standard. While unstated in the specification - but
> discussed within technical meetings - the resulting authentication
> protocol had to be simpler, stronger and provide a better UX than
> ISO-7816 smartcards with X.509 digital certificates (which provided the
> dl.acm.org/doi/abs/10.1145/1373290.1373293> as early as in the late '90s
> _never_ leaves the computing device. This allows RPs to choose
>
> any operation is permissible;
> * If one Security Key and the computing device have a hardware secure
> based credential is necessary
>
> Security Keys to support those needs. Platform computing devices and
> browsers evolved to supporting UP, and prompts for PINs or biometric
> options for UP/UV.
>
> Apple, in its earliest incarnations of adopting FIDO/WebAuthn conformed
> to these specifications, signalling great promise for the adoption of
> FIDO to the industry. Regrettably, on their own volition, they chose to
> bank-both-keys-safe-deposit-box-arshad-noor/>. Google and Microsoft, the
> "synchronized passkey" bandwagon.
>
> And, so here we are now. The strongest authentication protocol since TLS
> ClientAuth, has been turned upside down and all privacy promises have
> been broken in synced passkeys. Even UP - a given, whose optionality was
> Level-1 delivered /device bound/ private keys, /transaction
> confirmation, Android Key Attestation, /and the investment of hundreds
> have to worry about where their passkey is, is a reflection of market
> power. What could have been solved with education, and the negligible
> cost of an additional Security Key for first-world consumers, was left
> at the wayside and we now have a confused ecosystem, potentially massive
> data-breaches-spiked-in-2023>, and complete loss of privacy for
>
> Bottom line? At WebAuthn level-1/Level-2, the FIDO ecosystem was at a
> place that enabled RPs to do the things you are trying to do - and you
> can still do them! You can even go further than the basics if you want -
> and the investments (policy, training, development, procurement, etc.)
> you have to make for the level of security you want.
>
> The FIDO/WebAuthn capability was expected to establish a baseline level
> of security and privacy that was higher than what smartcards+digital
> certificates offered; it is now "balkanized" and RPs are going to have
> to live with it.
>
> Arshad Noor
> StrongKey
>
> * Technically, it was/is possible to issue end-entities (aka users,
> applications, devices, etc.) multiple digital certificates that enable
> passwordless TLS ClientAuth to the same account; given its attendant
> cost, RPs that deployed PKIs just chose not to do it.
>
> ** The irony of the situation is, that a colleague just recently brought
> to my attention that Apple is requiring two (2) Security Keys when
> through their browser_ - see attached images.
> On 4/16/25 2:15 AM, Nico wrote:
>
> Hi FIDO Developers,
>
> We are in the process of implementing passkey support for our
> service and have encountered a specific scenario with Apple's
> "Automatic Passkey Upgrade" feature that we'd appreciate the
> community's insights on.
>
> saved password via iCloud Keychain autofill, the system may offer to
> "upgrade" that password credential to a passkey. In some cases,
> particularly noted with more recent updates, this upgrade seems to
> happen automatically or "silently" in the background shortly after
> the successful password login.
>
> call result. However, upon inspecting the authenticatorData
> associated with the created credential, we consistently find that
> both the userPresence (UP) flag and the userVerified (UV) flag are
> set to false (0).
>
> for a navigator.credentials.create() operation, User Presence is
> generally required (i.e., requireUserPresence defaults to true in
> authenticatorSelectionCriteria). RPs typically verify that the
> returned UP flag is true to ensure the user was actively involved in
> the creation ceremony. Consequently, our backend library (and likely
> many others strictly following the spec's intent for registration)
> rejects these credentials because the UP flag is false, failing the
> standard validation check.
>
> exact moment of passkey creation/. However, the result conflicts
> registration.
>
>
> 1. *Shared Experience:*Are other Relying Parties observing this
> Passkey Upgrade mechanism?
>
> * Are you strictly enforcing UP=true for create() and
> flow, and what are the security considerations?
>
> automatic upgrades and advising RPs on how to handle it?
> from the standard UP check for create() to accommodate this
> vendor-specific flow, or is adhering to the stricter
> interpretation preferred?
> following a password login, where the create() ceremony itself
> returned UP=false?
>
> We are trying to balance providing a smooth user experience
> (especially for Apple users encountering this feature) with
> maintaining robust security guarantees aligned with the WebAuthn
> specification. Any insights, experiences, or pointers to relevant
> discussions/documentation would be greatly appreciated.
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it,
> dev+uns...@fidoalliance.org>.
> fidoalliance.org/d/msgid/fido-dev/98a64458-82ee-4b62-b609-
> fidoalliance.org/d/msgid/fido-dev/98a64458-82ee-4b62-b609-
> b1c2a4df98c4n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> dev+uns...@fidoalliance.org>.
> ba0e-371c31bd556a%40strongkey.com <https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/9af8e610-2ffc-41e3-
> ba0e-371c31bd556a%40strongkey.com?utm_medium=email&utm_source=footer>.
>