Web specifications and security considerations

Should W3C specifications, following IETF practice, be required to include a 
"security considerations" section?

(Apologies if this is the wrong forum for this, but I don't know of a better one.)

I recently proposed that the core provenance specification, which is about to be 
published for last call review, should include a "security considerations" 
section.  There was no support for this in the working group, for reasons that 
were, roughly, "this is just a data format, not a protocol, so it doesn't need 
security considerations".  I think that reasoning is flawed, as security needs 
to be considered pervasively across specifications that are used to build an 
application.  I suggest that many of the serious security problems that 
web/internet users face today have components that involve abuse of "data 
formats" rather than protocols - phishing, cross-site scripting, leakage of 
confidential/private information, etc.

IETF specifications are required to include a security considerations 
(http://tools.ietf.org/html/rfc2223#section-9, 
http://tools.ietf.org/html/rfc4677#section-8.4.4, 
http://tools.ietf.org/html/rfc3552).  My experience with editing and reviewing 
IETF specifications is that this requirement does prompt consideration by the 
designers, and more importantly by reviewers, of security issues that may be 
raised by new specifications.

(Another response to my proposal was that it could be done separately as a best 
practice note, because it's not part of the main specification and will probably 
need to be updated after the specification is published.  My concern with 
separate publication as a practice note is that, if it gets done at all, it 
won't receive the same level of reviewer attention.)

Considering security is not a pervasive part of the W3C culture in the way that 
it is in the IETF, but I am raising for consideration that we should be 
considering steps to make it so.

#g
--

Received on Friday, 13 July 2012 05:27:26 UTC