���OCCI Security Sections





OCCI Core 



Since the OCCI Core and Model specification describes a model, not an interface or protocol, no specific security mechanisms are described as part of this document. However, the elements described by this specification, namely type instance attribute mutability, Category, Kind, and Mixin instantiations; Entity, Resource, Link, and Action subtypes,  whether direct or indirect; resource or collection manipulation; and the discovery mechanism need to implement a proper authorization scheme, which MUST be part of a concrete OCCI rendering specification, part of an OCCI specification profile, or part of the specific OCCI implementation.

Concrete security mechanisms and protection against attacks SHOULD be specified by OCCI rendering specification. In any case, OCCI rendering specifications MUST address transport level security and authentication on the protocol level.

All security considerations listed above apply to all (existing and future) extensions of the OCCI Core and Model specification.[a]



Considerations:

1. no security, its a *model*, not an interface, or protocol etc.

2. resources described by this model need to implement an authorization scheme.  That scheme could part of an OCCI rendering specification, part of an OCCI specification profile, or an implementation detail of the specific OCCI implementation.

3. resource einzeln aufzaehlen und diskutieren

4. OCCI rendering specifications SHOULD specify security mechanisms to protect the query interface.

5. Transport level security and authentication are protocol level issues, and MUST be addressed by the OCCI renderings.

6. All security considerations listed above apply to all (exsisting and future) extensions of the OCCI Core specification.





OCCI Infrastructure



The OCCI Infrastructure specification is an extension to the OCCI Core and Model specification [CITATION]; thus the same security considerations as for OCCI Core and Model specification apply here.[b]





OCCI HTTP Rendering



The OCCI HTTP rendering assumes HTTP or HTTP-related mechanisms for security. As such, implementations SHOULD support TLS [CITATION] for transport layer security.

Authentication SHOULD be realized by HTTP authentication mechanisms, namely HTTP Basic or Digest Auth [CITATION], with the former as default. Additional profiles MAY specify other methods and should ensure that the selected authentication scheme can be renderable over the HTTP or HTTP-related protocols.

Authorization is not enforced on the protocol level, but SHOULD be performed by the implementation. For the authorization decision, the authentication information as provided by the mechanisms described above MUST be used.

Protection against potential Denial-of-Service scenarios are out of scope of this document; the OCCI HTTP Rendering specifications assumes cooperative clients that SHOULD use selection and filtering as provided by the Category mechanism whereever possible. Additional profiles to this document, however, MAY specifically address such scenarios; in that case, best practices from the HTTP ecosystem and appropriate mechanisms as part of the HTTP protocol specification SHOULD be prefered.

As long as specific extensions of the OCCI Core and Model specification do not impose additional security requirements than the OCCI Core and Model specification itself, the security considerations documented above apply to all (existing and future) extensions. Otherwise, an additional profile to this specification MUST be provided; this profile MUST express all additional security considerations using HTTP mechanisms.[c]

 

Considerations:

1. protocol! -> TLS, authentication, (authorization -> done *in* endpoint

2. TLS: TLS via HTTPS

3. TODO rewrite: authentication: HTTP-Auth (ref!) is default, but optional authentication method.  

4. Additional profiles MAY specify other methods, which may expand or replace HTTP-Auth

5. authorization: authorization is not enforced on protocol level, but within the endpoint accessed via the protocol.  The endpoint MUST use the authentication information provided by the authentication method specified above.

6. Note: potential Denial-of-service issues are not addressed in this discussion, which (in DoS context) expects cooperative clients.  An additional profile MAY specifically address DoS issues. (TODO: check HTTP spec, best practices etc).

7. As long as OCCI core extensions don't impose additional security considerations than OCCI core itself, the sec. cons. documented here apply for all (existing and future) extensions.  If those extensions do impose additional security constraints, an additional profile to *this* specification must be provided which describes the expression of those constraints in HTTP. 







[a]Normative text.

[b]Normative text.

[c]Normative text.