Re: [w3c/browser-payment-api] Send HTMLIFrameElement.allowPaymentRequest to HTML spec (#311)

I chatted more with Chrome folks and want to propose the following:

1. Rename the attributes to "allow" and "allowpolicy". The latter probably could use some bikeshedding, but I like "allow" because it matches the existing allowfullscreen, etc. 
2. For v1, just ship the "allow".
3. That gives us some breathing room to hash out all the details of v2 that includes:
  -full policy attribute. Maybe we'd call this "allowpolicy", or maybe we just let "allow" accept either syntax?
  -response headers
  -"disallow" attribute that is the corollary to allow

The things we lose here are v1 will have no way to apply policies to:
1. the top-level page.
2. an subframe that redirects or otherwise navigates itself to a different origin. A navigation via the iframe's src attribute would work fine though.

I think both of those are totally fine to not have in v1. The important use cases are met and we have a path towards the full thing eventually that meets all the use cases.

@annevk I'm not sure I understand what you mean about the attribute meaning something different if you also supply the header. The header is an complementary way of setting a policy. If you supply both, then the feature would be enabled if you allowed it with either one. The header doesn't change what the attribute does though. Does that make sense?

Re: Edge/Safari: We've reached out to both of them, but haven't heard back. When we talked to Safari folks about the general idea of feature policy months ago, they said that the general idea of enabling/disabling features at the frame level made sense. We didn't have a concrete API proposal at the time though.

-- 
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/browser-payment-api/issues/311#issuecomment-264038561