[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: 
"""
The specifications that this work product consists of do raise 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 some references to starting points for securing the Open Data services as specified. Open Data is a REST-full multi-format service that depends on other services and thus inherits both sides of the coin, security enhancements and concerns alike from the latter.

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 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.
"""


Minor edits to further approach readability.

> 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