Revert activation relaxation in show() -- find a general platform solution instead

[marcoscaceres]

Problem

PR #1009 changed the transient activation requirement in show() from a hard requirement to a MAY, with security mitigations left to implementer discretion. The stated motivation was supporting redirect flows where activation is lost during navigation.

The problem is real. The solution is not right.

Why this is wrong

Turning a hard requirement into a MAY means a conformant browser can skip the activation check entirely, with no normative constraints on when or how. The security considerations section added by #1009 describes mitigations browsers "may" apply -- none of which are required. That is not a spec constraint, it is a suggestion.

This also sets precedent. The Digital Credentials API is now citing this exact change to justify the same pattern in their spec. WebAuthn has the same gap with conditional mediation. Every API with a transient activation requirement is solving the redirect problem independently, inconsistently, and in ways that leave the door open for abuse.

The right fix

WICG Capability Delegation was working toward a general solution: explicit, named, consumed delegation of activation through a trusted call chain via postMessage. The originating page explicitly passes a typed activation capability to the destination. The intent has a chain of custody. The platform can verify it was handed off intentionally and consumed exactly once.

This is the correct model. It stalled. The right response is to revive it as a joint effort across Payment Request, Digital Credentials, and WebAuthn, and to define the primitive at the HTML level.

Proposal

1. Revert [Spec] Relax user activation requirement for show() #1009 (or replace with a note acknowledging the open problem)
2. Open a joint effort with Digital Credentials and WebAuthn to bring a sanctioned-continuation primitive to HTML/WHATWG
3. Once that primitive exists, update Payment Request and other affected specs to use it

I recognise reverting may affect deployed implementations. Happy to discuss how to handle the transition.

[marcoscaceres]

For context, this is part of a platform-wide pattern -- raised with the TAG at w3ctag/design-reviews#1213

[RByers]

I'm not sure this framing is correct. I left some big-picture thoughts in the TAG issue. But for payments specifically, the problem is handling the case of a user clicking to pay from one page, which redirects to another page completely to handle the payment there (not an iframe or a popup window). Capability delegation says nothing about that problem, right? I'm all for discussing better solutions, but we need to start with an agreement on the problem we're aiming to solve.

In general, in chromium we have found user activation restrictions to be useful in two cases:

1. Preventing abuse from iframes within a page. Permissions policy and capability delegation work together to ensure powerful capabilities can only be used in cross-origin subframes when ancestor frames have opted in.
2. Throttling annoying behavior in the main frame. Eg. a page can open only one pop-up per tap.

When we've tried to use user activation restrictions to fully prevent abuse in the main frame, it's largely failed. Eg. requiring a user activation for history.pushState just caused pages to add annoying "click here to keep reading" buttons. The fundamental problem here is not that we can't delegate the activation signal properly, it's that there is very little meaning in the activation signal itself. Our larger vision for properly solving this is problem is to replace "activation" constraints with browser-controlled in-page UI ala PEPC. Then, for example, when a user taps on what we know is UI for using a webcam, we confidently know we have a signal that the user wants to use their webcam (not just "keep reading").

So in the payments context I'd suggest maybe the right long-term fix is something like a <payment> PEPC element which, once tapped, unlocks all browser-based payment UI even across redirect chains. The problem is that this is a HUGE activation lift which can really only start once all engines have some PEPC support. Until then, I think we're stuck with pragmatic hacks like what WPWG has long ago resolved on here following their consensus process with active members in the group.