/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."