Changes between Version 34 and Version 35 of UniformClearinghouseAPIV2
- Timestamp:
- 01/22/14 09:03:29 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
UniformClearinghouseAPIV2
v34 v35 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: 464 464 465 - A 'speaking -for' option containing the URN of the user being spoken for465 - A 'speaking_for' option containing the URN of the user being spoken for 466 466 467 467 - 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). 468 468 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.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. 470 470 471 471 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: 644 644 # slice_urn: URN of slice for which to get member’s credentials 645 # options: Potentially contains ‘speaking -for’ key indicating a speaks-for645 # options: Potentially contains ‘speaking_for’ key indicating a speaks-for 646 646 # invocation (with certificate of the accountable member 647 647 # in the credentials argument) … … 848 848 # Arguments: 849 849 # member_urn: URN of member for which to retrieve credentials 850 # options: Potentially contains ‘speaking -for’ key indicating a speaks-for850 # options: Potentially contains ‘speaking_for’ key indicating a speaks-for 851 851 # invocation (with certificate of the accountable member in the credentials argument) 852 852 #