/Docs/G/Kantara-UMA-Text-CmA/Clause/RSO/AP_Delegate-Protection_0.md
Document views: Document Xray Visual Cicero Print   Source views: Source JSON(ish)   On GitHub: File ~PageRank   (rare: 'ShowMe' 1)
Title: {Resource_Server_Operator}-{Authorizing_Party}: Delegate-Protection

Text: For the period that the {Resource_Server_Operator} and {Authorizing_Party} have mutually agreed to serve in these respective roles for each other, the {Resource_Server_Operator} gains an obligation to the {Authorizing_Party} to delegate protection services to the {Authorization_Server_Operator} for the set of protectable resources for which it represents this capability to the {Authorizing_Party}, and to respect the authorization data that the {Authorization_Server} has associated with an {RPT} when the {Resource_Server} subsequently allows or disallows access by the {Client} that presented that {RPT}.

Comments: The original condition was "When the {Authorization_Server} issues a {PAT} to a {Resource_Server} and as long as the {PAT} is valid". That is, it relied on later action that involved the {Authorization_Server_Operator}. We now suspect this is much too late, and inappropriately entangling with a third party. The original commentary on this condition was "Once the {Authorization_Server_Operator} becomes the {Authorizing_Party}'s authorization proxy, it begins relying on the {Resource_Server_Operator} in other, more specific ways. The {Resource_Server} has the opportunity to inspect AM-issued permissions or take other actions that delegate protection responsibility to the {Authorization_Server} at a later stage, but its responsibility for respecting them begins now. The specific protection services made available to the {Resource_Server} by the {Authorization_Server} differ depending on the {RPT} profile in use. This obligation can be removed through {PAT} revocation."