Changes between Version 34 and Version 35 of UniformClearinghouseAPIV2


Ignore:
Timestamp:
01/22/14 09:03:29 (6 years ago)
Author:
mbrinn@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UniformClearinghouseAPIV2

    v34 v35  
    463463Accordingly, a Federation Registry and associated Authorities should support speaks-for API transactions. These API transactions use the same signatures as the calls described in this document, with these enhancements:
    464464
    465 - A 'speaking-for' option containing the URN of the user being spoken for
     465- A 'speaking_for' option containing the URN of the user being spoken for
    466466
    467467- A speaks-for credential in the list of credentials: a statement signed by the user indicating that the tool has the right to speak for the user, possibly limited to a particular scope (e.g. slice, project, API call, time window).
    468468
    469 The service call is then required to determine if the call is being made in a speaks-for context or not (that is, the ‘speaking-for’ option provided). If so, the call must determine if the tool is allowed to speak for the user by checking for the presence of a valid speaks-for credential and the spoken-for user’s cert. If so, the call should validate if the user is authorized to take the proposed API action. If so, the action is taken and accounted to the user, with identity of the speaking-for tool logged. If the call is ‘speaks-for’ but any of these additional criteria are not met, the call should fail with an authorization error. If the call is not a ‘speaks-for’, then the normal authorization is performed based on the identity (certificate) provided with the SSL connection.
     469The service call is then required to determine if the call is being made in a speaks-for context or not (that is, the ‘speaking_for’ option provided). If so, the call must determine if the tool is allowed to speak for the user by checking for the presence of a valid speaks-for credential and the spoken-for user’s cert. If so, the call should validate if the user is authorized to take the proposed API action. If so, the action is taken and accounted to the user, with identity of the speaking_for tool logged. If the call is ‘speaks-for’ but any of these additional criteria are not met, the call should fail with an authorization error. If the call is not a ‘speaks-for’, then the normal authorization is performed based on the identity (certificate) provided with the SSL connection.
    470470
    471471Aggregates are also encouraged to support speaks-for authentication and authorization, but this is an aggregate-internal policy and implementation decision, and outside the scope of this document.
     
    643643# Arguments:
    644644#   slice_urn: URN of slice for which to get member’s credentials
    645 #   options: Potentially contains ‘speaking-for’ key indicating a speaks-for
     645#   options: Potentially contains ‘speaking_for’ key indicating a speaks-for
    646646#      invocation (with certificate of the accountable member
    647647#      in the credentials argument)
     
    848848# Arguments:
    849849#    member_urn: URN of member for which to retrieve credentials
    850 #    options: Potentially contains ‘speaking-for’ key indicating a speaks-for
     850#    options: Potentially contains ‘speaking_for’ key indicating a speaks-for
    851851#        invocation (with certificate of the accountable member in the credentials argument)
    852852#