The internet needs a standard for setting up one-time verification codes. Apple should draft one.
SMS codes are effortless, but less secure.
One-time verification codes offer a more secure alternative, but require a password manager — and an initial handoff that lacks an internet standard.
Try this demo of an ideal handoff and verification codes in general: https://otpauth.dev
Apple and Google have similar recommendations for this handoff, but one difference can improve the user experience (or it hold back) by allowing a password manager to suggest the right account (or none at all) to add a verification code to.
QR codes are most common way to set up a verification code today. Users are often prompted to scan one with an “authenticator app.” These QR codes are just an encoded URL like this example:
otpauth://totp/Example:username?secret=key&issuer=example.com
The first part of the handoff is the otpauth scheme: https://iana.org/assignments/uri-schemes/prov/otpauth
Google and Microsoft are mentioned, but the scheme is not limited to any one password manager. Apple supported it for years and now officially: https://developer.apple.com/videos/play/wwdc2024/10125/?time=751 (timecode 7:51)
The second part is the otpauth specification, which is perhaps an industry standard but not an Internet Standard.
Apple and Google are aligned but offer different recommendations on how to identify the issuer of a verification code.
Google recommends using both the “issuer label prefix” and “issuer parameter” — and that they should be equal. (November 2018) https://github.com/google/google-authenticator/wiki/Key-Uri-Format
Apple suggests using a domain name for the “issuer parameter” and a proper name for the “issuer label prefix” — which somewhat conflicts with Google. (June 2021) https://developer.apple.com/documentation/authenticationservices/securing-logins-with-icloud-keychain-verification-codes
A password manager can ideally suggest the right account(s) at the right time. This saves time but also avoids the user attaching verification codes to the wrong account. The most direct way to identify those accounts is to match a domain name.
1. Not every browser or platform shares the domain name or other heuristics during a handoff on the same device.
2. QR codes in particular need the domain name included in the URL (and encoded in the image) for handoff.
Always include a domain name!
Goggle’s format is not the industry standard and Apple’s version was never identical, so an update alone to Apple Developer would help.
But if Apple wants more developers to adopt one-time verification codes, otpauth needs a draft internet standard.
@andrewe How can I help?
1. You can raise (or continue to raise) the issue with Authentication Experience. Apple and Google should resolve different recommendations for issuer label prefix and issuer parameter. (IETF seems logical given HOTP and TOTP RFCs — or would WICG make sense?)
2. You can encourage Developer Relations to update docs and promote otpauth (now that Apple has dropped apple-otpauth). Absent a draft, “strong opinion, loosely held” on issuer label (proper name) & issuer parameter (domain).
I created https://otpauth.dev months ago but recently Canada Revenue Agency (CRA; similar to IRS) began using TOTP. However, setup only offers QR code and encoded otpauth handoff URL follows Google recommendations (label should equal parameter). Example:
otpauth://totp/CRA%2FARC?secret=KEY&issuer=CRA%2FARC
Passwords app was therefore unable to suggest credentials for CRA domain: cra-arc[.]gc[.]ca