-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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. |
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. |
The W3C organizationally does not have any problem in principle with referencing WHATWG standards. (And incidentally the WHATWG is not a private organization.) |
@adamroach how can it be the authority if implementations follow something else? |
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. |
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.
The text was updated successfully, but these errors were encountered: