At first glance, the spec seems a bit informal, i.e., lacking a clear processing model. Such a model would make it clearer what happens in the case of nested iframes. Is the <code>allowpaymentrequest</code> attribute needed on the iframe at each origin boundary between the browsing context that wants to be allowed to make payment requests and the toplevel browsing context, or is it needed on more or fewer iframes?

Also, why is this extending only <code>HTMLIFrameElement</code> and not also <code>HTMLFrameElement</code> and <code>HTMLObjectElement</code>? Those are the three interfaces that have a <code>contentDocument</code> property. That said, the allegedly-deprecated (the editor's draft sort of agrees) <code>getSVGDocument()</code> seems to be on 2 of the 3 (not <code>HTMLFrameElement</code>, but with <code>HTMLEmbedElement</code> added. Maybe a common interface here is needed...

In particular the spec should be using https://html.spec.whatwg.org/#allowed-to-use instead of the undefined term "allowed to make payment requests". It answers @dbaron's question about nesting (you need it at every iframe; origins are not consulted except in the initial check inside the PaymentRequest constructor---but see below for more on that).

All other allow* attributes are currently only on HTMLIFrameElement.

Also this needs [CEReactions] since it's a reflected content attribute.

Ideally this should be pull-requested to HTML as it defines a new content attribute, but developing it in the payment request spec is fine for now.

Also "the browsing context of the script calling the constructor whose origin..." is poorly defined. Scripts don't have browsing contexts and browsing contexts don't have origins. We shouldn't be doing call-stack-walking type checks about the scripts calling things. And "different from" is not the correct check. You instead want "The current settings object's origin is not same-origin with its top level browsing context's Window's relevant settings object's origin.

FWIW, "allowed to use" and the general uplifting to HTML is https://github.com/w3c/browser-payment-api/issues/311.

See https://github.com/whatwg/html/issues/2112 for a discussion of making it easier for spec authors to ask the question "am I being invoked cross origin"

Reviewed at TAG Boston f2f. Should followup that @annevk and @domenic comments were addressed.

Also note from our minutes: Resolved: Attribute proposed in the spec LGTM

In general this has been largely straightened out (as long as you ignore the references to the W3C HTML fork in the Payment Request, and use the corresponding definitions in the HTML Standard) by the heroic work of @zcorpan. He's also added web platform tests, which is super-great.

I still have an open action item to see if https://github.com/whatwg/html/issues/2112 is still worthwhile and worth pursuing further as something generally useful, but the payment request-specific stuff has been straightened out nicely for now.

Extracting from the minutes: we spent some time figuring out whether this attribute was appropriate for the iframe tag or whether it belonged in the sandbox attribute as a directive. It does seem correct to make it an attribute of the tag itself, since it is currently consistently the case that sandbox directives re-enable things that the presence of the sandbox attribute disables.

That wraps things up from a TAG review perspective