Michael,

The plan is to follow Sun's example in relying on HTTP authentication mechanisms (e.g. basic, digest, certificates) and possibly OAuth for authentication rather than doing request signing. Signing is mostly useful where you need to generate signed requests for untrusted clients - for example a URL to download an eBook from S3 - and writing your own signing mechanisms can be dangerous (as proven by Amazon's request signing vulnerability).

This is of course open to discussion but I think it is best to avoid imposing our wishes on clients in this regard - some sites may not be able to use encryption (nor want to for performance reasons) and others may require policy compliance in the form of e.g. kerberos support.

Sam

On Fri, Aug 28, 2009 at 5:10 AM, Michael Behrens <michael.behrens@r2ad.com> wrote:
I noticed that a security section is needed in the doc.

I'm not a security expert, however I like how Rackspace cloud modeled their security as it starts with an authentication URI which returns in the response a session unique access URI for all subsequent service calls (assuming the authentication was successful). This creates a session of sorts which will expire after a time or could end upon request I believe.

I noticed that the Sun Cloud API takes a different approach which requires basic authentication for every request.

Anyway - just wanted to make sure we get something captured in this area.  Since the RackSpace APIs are open now (right?) - there model might be good to examine (as well as others of course).

http://www.rackspacecloud.com/cloud_hosting_products/servers/api

http://kenai.com/projects/suncloudapis/pages/CommonBehaviors


Michael Behrens
R2AD, LLC
(571) 594-3008 (cell)
(703) 714-0442 (land)


_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg