fix: restore transient activation requirement in show()

[marcoscaceres]

Reverts the relaxation introduced in #1009 and removes the non-normative "User activation requirement" section.

What changed

• Restores [=transient activation=] as a hard requirement in show() (removes the MAY)
• Removes the "User activation requirement" security considerations section
• Replaces both with a note acknowledging the redirect flow problem and pointing to the general solution being tracked in Revert activation relaxation in show() -- find a general platform solution instead #1064

Why

The MAY introduced in #1009 means a conformant browser can skip the activation check entirely with no normative constraints. The security mitigations in the removed section were all non-normative suggestions. That is not a spec constraint.

This is also part of a pattern: Digital Credentials and WebAuthn have the same problem and are reaching for the same local workarounds. The right fix is a sanctioned-continuation primitive at the HTML level (see WICG Capability Delegation), tracked in #1064.

Keeping the activation requirement strict here maintains pressure to find the general solution rather than normalizing per-spec workarounds.

closes #1064

The following tasks have been completed:

• Modified Web platform tests (link)

Implementation commitment:

• WebKit (link to issue)
• Chromium (link to issue)
• Gecko (link to issue)

Optional, impact on Payment Handler spec?

---

Preview | Diff

[ianbjacobs]

Please don't merge until we've had an opportunity to discuss this.

[marcoscaceres]

haha, totally not. Don't worry... this is going to be a long discussion :)

We have the PR template for good reason too.

[stephenmcgruer]

Hey Marcos; thanks for filing this and #1064 . Totally agree that what's in the spec right now is a hack; we had redirect flows that we needed to have working, and our initial attempt to work with the user activation flows folks ran out of steam, so we did the hacky thing. Time to pay down the debt (and thank you for taking on debt you didn't cause!).

I think I would mostly be ok with this revert, though it would be nice to not land it until we see progress in the general solution.

Given Chromium would become (and would remain) non-compliant, however, what do you think about the spec noting that some user agents are known to have non-compliant behaviour here? Too much of a violation of spec purity? :)

[marcoscaceres]

We could definitely add a big red note to the spec here, as I think this is a really important issue and highlighting what’s been tried in practice is important. Again, the problem identified is very real and critical we find a solution for it.

Should we draft something up?

[stephenmcgruer]

Sorry for the delay! Yes, let's draft something up, wdyt of:

 <div class="note">
              Redirect flows can cause legitimate loss of transient activation
              before a call to {{PaymentRequest/show()}}. This is a known
              platform-wide problem affecting Payment Request, Digital
              Credentials, WebAuthn, and other APIs that require user
              activation. A general solution is being tracked in <a href=
              "https://github.com/w3c/payment-request/issues/1064">issue
              #1064</a>. Currently, some Chromium-based user agents
              are known to have non-compliant behavior here to allow certain
              calls to Payment Request to not require user activation.
</div>

? Happy to iterate. Also curious what @ianbjacobs thinks

[ianbjacobs]

Could we say "legacy" instead of "non-compliant"?

[marcoscaceres]

Thanks for the suggestions @stephenmcgruer and @ianbjacobs. I've updated the note to incorporate both — using "legacy" per Ian's suggestion, and keeping it implementation-neutral (not calling out Chromium specifically):

<div class="note">
  Redirect flows can cause legitimate loss of transient activation
  before a call to {{PaymentRequest/show()}}. This is a known
  platform-wide problem affecting Payment Request, Digital
  Credentials, WebAuthn, and other APIs that require user
  activation. A general solution is being tracked in <a href=
  "https://github.com/w3c/payment-request/issues/1064">issue
  #1064</a>. Some user agents have legacy behavior that allows
  certain calls to {{PaymentRequest/show()}} without requiring
  user activation.
</div>

WDYT?

[RByers]

FWIW I don't believe we should revert this. Without a viable replacement (no, capability delegation in it's current form is not it), Chrome will not unship our behavior here. So it would seem to be to be spec-fiction to have the spec indicate it's not allowed. Let's try to agree on a realistic plan to fully solve this use case (#1064) before suggesting we break the fix we have.

[marcoscaceres]

As it stands, this documents single-engine behavior as a literal standard. WebKit has no plans to implement this, so its inclusion in the spec was accidental: I believe the PR template that prevented such single-engine additions was somehow disregarded without multiple implementer commitment (this should have never landed in the spec in the first place).

I think we should remove the normative text and work on correcting it properly through the Capabilities proposal. The appropriate place to document browser quirks is within the Web Compat specification, if we want to do that.