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

Add Security Considerations and Privacy Considerations sections #7

Closed
adamroach opened this issue Aug 10, 2016 · 5 comments · Fixed by #35
Closed

Add Security Considerations and Privacy Considerations sections #7

adamroach opened this issue Aug 10, 2016 · 5 comments · Fixed by #35
Assignees

Comments

@adamroach
Copy link

This is a recommendation from the Security and Privacy Checklist review. See https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?usp=sharing for additional detail

The Payment Method Identifier specification should at least point to a URI spec (e.g., RFC 3986) and its security considerations section.

@sideshowbarker
Copy link
Contributor

The Payment Method Identifier specification should at least point to a URI spec (e.g., RFC 3986) and its security considerations section.

I agree that it should point to something but I don’t agree it should be the (legacy) URI spec. It should instead be https://url.spec.whatwg.org/#security-considerations and if what is currently there isn’t sufficient, then bugs should be raised against that (the current URL standard) to get that section made more complete in any ways it which it is currently deficient.

@adamroach
Copy link
Author

I have a problem in principle (independent of the URL issue) with normatively referencing specifications produced by a private organization with no clear governance model and no formal IPR policy.

I have a problem in particular with the WHATWG URL specification because uncoordinated competing specifications that claim to cover the same technology are actively harmful to interoperation. The IETF remains the authority for specification of URLs.

@sideshowbarker
Copy link
Contributor

I have a problem in principle (independent of the URL issue) with normatively referencing specifications produced by a private organization with no clear governance model and no formal IPR policy.

The W3C organizationally does not have any problem in principle with referencing WHATWG standards. (And incidentally the WHATWG is not a private organization.)

@annevk
Copy link
Member

annevk commented Aug 11, 2016

@adamroach how can it be the authority if implementations follow something else?

@adrianhopebailie
Copy link
Contributor

The W3C organizationally does not have any problem in principle with referencing WHATWG standards. (And incidentally the WHATWG is not a private organization.)

I'm not sure that's entirely true for all WHATWG specs. There was certainly a lot of back-and-forth recently about this exact issue in WebAppSec. We need to tread carefully here or we will simply create delays for ourselves in resolving this later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants