Changes between Version 34 and Version 35 of UniformClearinghouseAPIV2

Timestamp:

01/22/14 09:03:29 (10 years ago)

Author:

mbrinn@bbn.com

Comment:

--

UniformClearinghouseAPIV2

@@ -463 +463 @@
 Accordingly, 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:
 
-- A 'speaking-for' option containing the URN of the user being spoken for
+- A 'speaking_for' option containing the URN of the user being spoken for
 
 - 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).
 
-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.
+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.
 
 Aggregates 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.
@@ -643 +643 @@
 # Arguments:
 #   slice_urn: URN of slice for which to get member’s credentials
-#   options: Potentially contains ‘speaking-for’ key indicating a speaks-for 
+#   options: Potentially contains ‘speaking_for’ key indicating a speaks-for 
 #      invocation (with certificate of the accountable member 
 #      in the credentials argument)
@@ -848 +848 @@
 # Arguments:
 #    member_urn: URN of member for which to retrieve credentials
-#    options: Potentially contains ‘speaking-for’ key indicating a speaks-for 
+#    options: Potentially contains ‘speaking_for’ key indicating a speaks-for 
 #        invocation (with certificate of the accountable member in the credentials argument)
 #