OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[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=35043#action_35043 ] 

Gilbert Pilz commented on CAMP-18:
----------------------------------

Oracle has reviewed Adrian's proposal and come to a consensus position on it. Although, for the sake of interoperability, we would prefer to define at least one (doesn't matter which) common authentication mechanism that every CAMP client could depend upon being implemented we can live with the current proposal *provided* it is amended to include some mechanism by which Providers can advertise which authentication mechanisms they support. We don't have any definite ideas on what this mechanism should look like, but it augmenting the PlatformEndpoint resource seems like an obvious place to begin.

> 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]