[OASIS Issue Tracker] Updated: (ODATA-380) Insert a section in protocol (and similar in JSON and ATOM) named 'Security Considerations' (before 'Conformance')

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/ODATA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Drees updated ODATA-380:
-------------------------------

    Proposal: 
Insert a section in protocol (and similar in JSON and ATOM) named "Security Considerations" before the conformance section. With content like: 
"""
This document raises no security issues. 

This section is provided as a service to the application developers, information providers, and users of Open Data version 4.0 giving references to starting points for securing the Open Data services described herein and that are assembled from other services they inherit transport and security features from.

For HTTP  relevant security implications please cf. the relevant sections of [[RFC2616]] (15 Security Considerations) and for the HTTP PATCH method [[RFC5789]] (5. Security Considerations) as starting points.
"""

The last paragraph for ATOM Format work product:

"""
For ATOM relevant security implications please cf. the relevant sections of [[RFC4287]] (8. Security Considerations), [[RFC5023]] (15. Security Considerations) and for the deleted-entry element: [[RFC6721]] (7.  Security Considerations) as starting points.
"""

Whereas the last paragraph in that section for JSON Format should read:

"""
For JSON relevant security implications please cf. at least the relevant subsections of [[RFC4627]] (hidden inside 6. IANA Considerations) as starting point.
"""

  was:Insert a section in protocol (and similar in JSON and ATOM) named "Security Considerations" before the conformance section. With content starting like: "This section is meant to inform application developers, information providers, and users of the security limitations in Open Data version 4.0 as described by this document." And in the following then mainly refer to HTTP or (JSON or ATOM as applicable) will move that to a new issue.


Rewrote proposal, to always start with a relaxing "we do not add any insecurity to the mix we want to talk you into using to open up all your data with" and added specific last paragraphs for the three work products Protocol, ATOM and JSON Format

> Insert a section in protocol (and similar in JSON and ATOM) named 'Security Considerations' (before 'Conformance')
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-380
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-380
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ATOM Format , OData JSON Format, OData Protocol 
>    Affects Versions: V4.0_CSD01
>            Reporter: Stefan Drees
>             Fix For: V4.0_CSD02
>
>
> We have some spurious overlaps with security considerations but are remarkably silent about it as a whole, when considereing, that we suggest opening up the silos of data. Although we rely on other protocols that handle transport and security, we should follow the role model of IETF in enforcing a security considerations section in each I-D. It should be quite cheap as we can refer to the security considerations of the underlying protocols (HTTP has some elaboratesubsections on this)
> This started from discussions and comments on ODATA-301 but to the reporter also seems like a very natural, reasonable and "expected" thing to be provided by the TC and inside the work products.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira