[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (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:all-tabpanel ]
Adrian Otto updated CAMP-18:
----------------------------
Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50827/camp-spec-v1.1-wd24-issue18.doc (was: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48065/camp-19-2013-01-30-r1.doc)
Updated concrete proposal for this issue.
HTTP Basic has not been chosen as an authentication scheme by any industry leading public cloud. Keeping it in scope as a normative requirement is a definite barrier to adoption of CAMP. This proposal removes the requirement for Providers to support any specific Authentication scheme, and adds a note encouraging Providers to select one of three listed Authentication schemes in order to simplify development of client tools that are intended to work with multiple Providers.
At the time of v.next for CAMP, if there is a pattern of consensus among Providers for what Authentication schemes are chosen, we can revisit the goal of identifying a single scheme that all providers implement as a lowest common denominator.
> 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: Adrian Otto
>
> 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]