Re: [w3c/payment-request] Editorial: relationship to Feature Policy spec (#822)

marcoscaceres commented on this pull request.



>        </h2>
-      <p data-tests=
-      "allowpaymentrequest/active-document-cross-origin.https.sub.html, allowpaymentrequest/active-document-same-origin.https.html, allowpaymentrequest/allowpaymentrequest-attribute-cross-origin-bc-containers.https.html, allowpaymentrequest/allowpaymentrequest-attribute-same-origin-bc-containers.https.html, allowpaymentrequest/basic.https.html, allowpaymentrequest/no-attribute-cross-origin-bc-containers.https.html, allowpaymentrequest/no-attribute-same-origin-bc-containers.https.html, allowpaymentrequest/removing-allowpaymentrequest.https.sub.html, allowpaymentrequest/setting-allowpaymentrequest-timing.https.sub.html, allowpaymentrequest/setting-allowpaymentrequest.https.sub.html">
-        To indicate that a cross-origin <a>iframe</a> is allowed to invoke the
-        payment request API, the <a>allowpaymentrequest</a> attribute can be
-        specified on the <a>iframe</a> element.
+      <p>
+        The <a data-cite="feature-policy">Feature Policy</a> specification
+        defines the "<code>payment</code>" feature and the <code><dfn data-cit=

> You cannot get to REC without two implementations right? 

Correct. 

> And implementations wouldn't be able to implement this any other way. Or would you leave this whole thing undefined or some such?

The Feature Policy would be undefined, but there is sufficient prose in the spec (in the constructor) that an implementation that does implement either the `allowpaymentrequest` attribute or the Feature Policy spec would behave in conforming manner (and could be demonstratively shown to behave in a conforming manner).      

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