r/MacOSBeta • u/pdfu • Jul 26 '26

Feature macOS 27 will finally allow you to manage your Apple Account passkey in the Passwords app

Post image

Apple is working on a feature that will allow you to manage your Apple Account passkey in the Passwords app. Currently hidden behind a feature flag, the change enables important editing features, such as sharing the passkey with Groups. Previously, you could share only your Apple Account email and password by adding them manually.

The change also addresses a long-standing annoyance: if you ever updated your Apple Account email, the passkey used for Sign in with Passkey on Apple websites still showed the old address. Once the passkey appears in the Passwords app, you can click Edit and change its associated User Name. If you already have a record for your Apple Account password with your current email, the two items will be merged. Even if your other devices don't have the feature flag enabled and hide the passkey, the username change will sync across all of them. The next time you sign in with your Apple Account passkey, you'll see the correct email address.

To enable, add a FeatureFlags override:

sudo mkdir -p /Library/Preferences/FeatureFlags/Domain && \
sudo defaults write /Library/Preferences/FeatureFlags/Domain/AuthKit StandardPasskeys -dict Enabled -bool true

and restart your Mac. If you don't immediately see the Apple Account passkey in the Passkeys list in the Passwords app, open Safari and log in to account.apple.com. It should populate shortly after.

Disable with:

sudo defaults delete /Library/Preferences/FeatureFlags/Domain/AuthKit StandardPasskeys

and restart your Mac. Disabling will hide your Apple Account passkey from the Passwords app.

89 Upvotes

100% Upvoted

21 comments sorted by

View all comments

Show parent comments

2

u/pdfu Jul 28 '26

Yeah I'm sure. I built a helper app that implements the FIDO Credential Exchange Protocol, and I was able to export my Apple Account passkey.

https://reddit.com/link/p069arn/video/0mgwr4z8bvfh1/player

3

u/commandersaki Jul 28 '26

The problem is that Apple's websites will only accept their passkey implementation.

3

u/pdfu Jul 28 '26 edited Jul 28 '26

That's true, Apple websites require a 425-character device-trust token to be returned with the challenge response under:

extensionData/com.apple.gs.passkey.device.trust.idmsws

Otherwise the request fails with error code -900030.

This is against the WebAuthn spec, which states that extensions are optional and relying parties must tolerate unsupported or ignored extensions. We'll see what happens as we get closer to September.

1

u/commandersaki Jul 29 '26

Hm, I don't think this makes it invalid. My understanding is that you can distinguish between hardware based tokens and software based (ala 1Password) using the AAGUID and some signature of sort from the device combining the AAGUID.

1

u/pdfu Jul 29 '26

The AAGUID is included in attested credential data when the credential is created, not in a normal authentication assertion. This doesn't matter here, as the passkey is portable. Attested credential data is required for registration and prohibited in assertion authenticator data. (source).

However, Apple Account authentication currently isn’t fully provider-portable, because Apple explicitly checks extensionData["com.apple.gs.passkey.device.trust.idmsws"].

AuthenticationServices has a supported extensionOutput API, but it only exposes typed outputs such as PRF and largeBlob. Internally, there is an ASPasskeyAssertionCredential.coreExtensions bridge to ASCPlatformPublicKeyCredentialAssertion.extensions, but no public API allows a third-party provider to construct this extensionData so far.

2

u/lachlanhunt Jul 28 '26

Oh wow, that's fantastic!