Breaking down clause conditions so that each duty has only two parties

[xmlgrrl]

A candidate set of conditions, developed as part of an exercise looking at a large subset of the existing clauses to date, can be found here: http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Candidate/Conditions_0.md

Below is my analysis of how the conditions might apply to specific duties, with the potential end result of revising some clause structures (this was from an email I sent on Jan 7):

Conditions (my names here were informal; Jim gave them slightly different names in the file and we can change them at will):

RSO-ASO role establishment: For the period that the Resource Server Operator and Authorization Server Operator have mutually agreed to serve in these respective roles for each other
RSO-AuthzP role establishment: For the period that the Resource Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other
ASO-AuthzP role establishment: For the period that the Authorization Server Operator and Authorizing Party have mutually agreed to serve in these respective roles for each other

Duties that depend on all three conditions (links here are to files linked off of 0.md's Source view):

(depending on what we decide regarding the discussion about respecting permissions) Duty.1 of AP_Delegate-Protection_0.md (probably modified to clarify that it reserves the right to apply its own local authorization processes)
Duty.1 of ASO_Register-Accurately-and-Timely_0.md (only to AuthzP, not also to ASO? why does it owe this to the ASO?)
(depending on what we decide regarding the discussion about respecting permissions) Duty.1 of Respect-Permissions -- or maybe it will end up being Disallow-Access-On-Insufficiency or something
Duty.1 of Follow-Policies-Accurately-and-Timely (only for AuthzP, not also to RSO? why does it owe this to the RSO?)

Continuing the exercise, we didn't give Introduce-Authorization-Server and Introduce-Resource-Server, respectively, the right condition because what precedes them is actually the process of the Authorizing Party consciously identifying which partner they want the other one to work with, not already having a valid PAT. So it needs to be something like this instead:

Conditions:

ASO choice acceptable to RSO: When more than one choice of an Authorization Server Operator is acceptable to a Resource Server Operator
RS nondefault AS choice interface: When the Resource Server has presented an interface to the Resource Owner that does not default to an automatic choice of Authorization Server
RSO meets ASO client credentials requirements: When the Resource Server has met any requirements for acquiring OAuth client credentials
(maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?)

Duty:
Duty.1 of Introduce-Authorization-Server (probably reworded to be more formal)

Conditions:
No preestablished ASO relationship with RSO: When the Authorization Server Operator has no preestablished relationship with the Resource Server Operator
RSO meets ASO client credentials requirements (haha, reuse again)
(maybe need other security precautions here, about OAuth redirects and registered callback endpoints? or can that be commentary?)

Duty:
Duty.1 of Introduce-Resource-Server (probably reworded to be more formal)

Out of all the clauses originally written, this leaves only the following to be analyzed afresh.

Adhere-to-Terms in both directions
Supply-Truthful-Claims
Is-Legitimate-Bearer
Request-Limited-Claims