[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-18) API Authentication/Authorization not clear and should leave scope for other auth mechanisms
[ http://tools.oasis-open.org/issues/browse/CAMP-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32019#action_32019 ]
Adrian Otto commented on CAMP-18:
---------------------------------
I suggest that we remove all normative statements that require any specific authentication mechanisms.
We should at least a discovery mechanism to identify what authentication schemes are supported by a given implementation.
I recognize our desire to have at least one common authentication mechanism available for interoperability reasons. The truth of the matter is that most service providers offering CAMP compliant services will be fitting them into a portfolio of other cloud computing services that already have at least one mechanism for authentication defined. Specifying a required scheme would cause several prevailing cloud service providers to ignore such requirements in our spec (and risk being considered non-compliant) in order to make their CAMP related service offering consistent with existing cloud services.
Whether an implementation uses best practices such as HTTPS or specific authentication schemes such as Basic Auth should really be beyond the scope of our charter. The additional value in interoperability afforded by a common required scheme is clearly outweighed by the certain resistance that service providers will exhibit in response to supporting the identified scheme.
> API Authentication/Authorization not clear and should leave scope for other auth mechanisms
> -------------------------------------------------------------------------------------------
>
> Key: CAMP-18
> URL: http://tools.oasis-open.org/issues/browse/CAMP-18
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Components: Spec
> Reporter: Anish Karmarkar
> Assignee: Gilbert Pilz
>
> The spec talks about basic auth requirement:
> "Each request will be authenticated using HTTP Basic Authentication [RFC2617] unless otherwise noted."
> (Above, what does "will" mean, is it intended to be a MUST?)
> Unless I missed it somewhere reading the spec, looks like it does not talk about other authentication/authorization mechanism such as OAuth2. OAuth2 is still a draft but in practice its implemented/used by many. For example, if a "application developer", might be able to use OAuth2 access token[1] as HTTP Authentication header[2] or in some cases as URI query parameter while calling a vendor's CAMP APIs.
> It sounds like the spec intends to mandate basic auth as the only authentication mechanism. Perhaps it should allow OAuth2 or other authorization/authentication mechanism as extensibility or keep it open and adopt OAuth2 as it evolves during spec development.
> [1]http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-7
> [2]http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19
> [This issue was drupal issue # 1086]
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]