Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define Content Security Policy for allowed Payment Pointer origins #29

Closed
adrianhopebailie opened this issue Oct 15, 2019 · 8 comments · Fixed by #193
Closed

Define Content Security Policy for allowed Payment Pointer origins #29

adrianhopebailie opened this issue Oct 15, 2019 · 8 comments · Fixed by #193
Assignees
Labels
pr193 New Web Monetization Specification Proposal specification Work required on specification

Comments

@adrianhopebailie
Copy link
Collaborator

From #14 (comment) originally posted by @justmoon

... make Web Monetization part of the Content Security Policy in the future. For instance, my CSP could determine which origins I allow for payment pointers:

Content-Security-Policy: default-src 'none'; monetization-src mywallet.com

Which would allow payment pointers starting with $mywallet.com.

@adrianhopebailie adrianhopebailie added the specification Work required on specification label Oct 15, 2019
@Malvoz
Copy link

Malvoz commented Oct 15, 2019

Consider that someone, somewhere made the decision not to have a CSP directive govern the Payment Request API, but instead as a policy-controlled feature named payment. That is why I initially proposed a Feature-Policy directive for web monetization, to align with that approach. See #28 (comment).

I don't think there's a need for a CSP directive if there is a FP feature...

@adrianhopebailie
Copy link
Collaborator Author

@Malvoz this is for a different purpose. This allows the site owner to define restrictions around the origins of Payment Pointers that are used.

Feature Policy would be for controlling which third-party contexts can be monetized.

Or am I misunderstanding?

@Malvoz
Copy link

Malvoz commented Oct 15, 2019

A document can impose a Feature-Policy on itself, e.g. by sending along a Feature-Policy HTTP header, or potentially using a <meta http-equiv="Feature-Policy" content="..."> element. So in that regard FP works the same as CSP.

In other words Feature-Policy can be delegated both using an HTTP header (which controls the document itself and third-parties), and the allow attribute which only affects nested content (this granular control isn't possible with CSP).

@adrianhopebailie
Copy link
Collaborator Author

Right, but it feels like in this case we're using FP to allow (or not) monetization and CSP to specify which Payment Pointers are allowed.

@Malvoz
Copy link

Malvoz commented Oct 15, 2019

That makes sense, these are 2 separate concerns. Sorry for the distraction.

@marcoscaceres
Copy link
Contributor

I've added Permission Policy integration in #214, but it would make sense to also restrict the origins from which the setup JSON is sourced.

@marcoscaceres
Copy link
Contributor

Noting, this would need to be added to the Fetch spec.... the WM spec could make note of it tho.

@marcoscaceres
Copy link
Contributor

CSP is now defined in PR #193

@AlexLakatos AlexLakatos added the pr193 New Web Monetization Specification Proposal label Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr193 New Web Monetization Specification Proposal specification Work required on specification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants