Intent to Prototype: Align error type thrown for 'payment' WebAuthn credential creation: SecurityError => NotAllowedError
Stephen Mcgruer
Contact emails
smcg...@chromium.orgExplainer
https://github.com/w3c/secure-payment-confirmation/issues/267Specification
NoneSummary
Correct the error type thrown during WebAuthn credential creation for 'payment' credentials. Due to a historic specification mismatch, creating a 'payment' credential in a cross-origin iframe without a user activation would throw a SecurityError instead of a NotAllowedError, which is what is thrown for non-payment credentials. This is a breaking change, albeit a niche one. Code that previously detected the type of error thrown (e.g., `e instanceof SecurityError`) would be affected. Code that just generally handles errors during credential creation (e.g. `catch (e)`) will continue to function correctly.
Blink component
Blink>PaymentsMotivation
As part of Secure Payment Confirmation (SPC), WebAuthn credentials with the 'payment' extension could be created in a cross-origin iframe before this was allowed for other WebAuthn credentials. When the ability to do this for all WebAuthn credentials was added in https://github.com/w3c/webauthn/pull/1801, an accidental spec misalignment was made. In the very specific case of credential creation in a cross-origin iframe without user activation, the SPC spec said to throw a SecurityError, whilst the WebAuthn spec said to throw a NotAllowedError. This misalignment has now been corrected at the specification level (https://github.com/w3c/secure-payment-confirmation/issues/267), and so left Chromium as non-compliant with the specification.
Initial public proposal
https://github.com/w3c/secure-payment-confirmation/issues/267TAG review
NoneTAG review status
N/A - minor change to existing specificationRisks
Interoperability and Compatibility
None
Gecko: N/A - minor change to existing specification. Note that SPC is not implemented or supported by Gecko.
WebKit: N/A - minor change to existing specification. Note that SPC is not implemented or supported by Gecko.
Web developers: No signals
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Is this feature fully tested by web-platform-tests?
Yes (but still testing the old behavior) - https://wpt.fyi/results/secure-payment-confirmation/enrollment-in-iframe.sub.https.html?label=experimental&label=master&alignedFlag name on about://flags
chrome://web-authentication-align-error-type-for-payment-credential-createFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseEstimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5160752715137024?gate=6260632086904832Stephen McGruer
Domenic Denicola
Note: We've done outreach to the WPWG members (https://lists.w3.org/Archives/Public/public-payments-wg/2025Feb/0008.html), and are following up with known partners directly.We don't have UseCounters here currently; I'm hoping to land some for M135, but this is such a niche case (creation within an iframe is rare/non-existent today in practice, and this further requires that you are catching and care about the specific error type for missing user activation) that I may request I2S without that data.
On Monday, February 24, 2025 at 10:34:46 AM UTC-5 Stephen McGruer wrote:
Flag name on about://flags
chrome://web-authentication-align-error-type-for-payment-credential-createFinch feature name
NoneNon-finch justification
None
Requires code in //chrome?
FalseEstimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5160752715137024?gate=6260632086904832This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/39f5811d-a696-4fa0-8caa-720c18880799n%40chromium.org.
Stephen Mcgruer
Domenic Denicola
Thanks Domenic,> Can you be sure to update these as part of shipping the new behavior?
Absolutely, sorry if that wasn't clear that we will be doing this. :)> Why no Finch flag?Because Chromestatus didn't ask me for one before reaching the I2P stage, and I missed this field when manually editing the email 😅. Naively, there will be a default Finch flag here from the base::Feature generated from the RuntimeEnabledFeature, and that Finch flag will act as a killswitch as needed. Is something more expected? (Do web platform launches use Finch rollouts nowadays? Been a while since I've been in the WP space!)