[w3c/payment-request] Revert activation relaxation in show() -- find a general platform solution instead (Issue #1064)

marcoscaceres created an issue (w3c/payment-request#1064)

## Problem

PR [#1009](https://github.com/w3c/payment-request/pull/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](https://github.com/w3c-fedid/digital-credentials/pull/486) 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](https://wicg.github.io/capability-delegation/spec.html) 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 #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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/1064
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/issues/1064@github.com>