Rather than worry (for now) about the form of documents that use our model text, we thought we would home in on just the term definitions, abbreviation definitions, and model clauses -- what we're collectively calling "model text". We're only partway towards an editor's draft reflecting the feedback we gathered last time. Model text items needing review and work: - Term and abbreviation definitions (revised, and red taken off token names) - Multi-party conditions and duties to pairwise (partially revised) - Distinguishing between delegatable and nondelegatable rights and responsibilities (possibly leveraging CARAT http://civics.typepad.com/files/carat_final_011400-1.pdf) (not revised) - Considering the need for conditions subsequent - The need for clauses dealing with security layers underneath UMA (see issue notes below) - Considering issue notes sprinkled throughout existing clause text - ...? The link we'll use persistently for the draft model text needing review is: http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/ If you go there now, you'll see a kind of table of contents, with entries for 0.md, Candidate, Clause, Comment, Terminology, and Z. If you go into 0.md and click the Document link at the top, you'll get an expanded view of the model text. If you go into Candidate, you'll see a list of pairwise "conditions" that will help us explode our too-complex multi-party conditions to meet the goal we discussed last time for breaking down all relationships between parties into pairs. Here is the analysis gone through to get this set of conditions for a large subset of the existing clauses, namely the relationships among the Authorizing Party (Alice), the Authorization Server Operator, and the Resource Server Operator, which end up getting bound by a protection API token or PAT. (Note that the clauses exposed in 0.md don't yet list out "multi-conditions" yet.) 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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/0.md ): - (depending on what we decide regarding the discussion about respecting permissions) Duty.1 of AP_Delegate-Protection_0.md http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/ASO_Respect-Permissions_0.md -- or maybe it will end up being Disallow-Access-On-Insufficiency or something - Duty.1 of Follow-Policies-Accurately-and-Timely http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/ASO/AP_Follow-Policies-Accurately-and-Timely_0.md (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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/AuthzP/RSO_Introduce-Authorization-Server_0.md and Introduce-Resource-Server http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/AuthzP/ASO_Introduce-Resource-Server_0.md, 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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/AuthzP/RSO_Introduce-Authorization-Server_0.md (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 http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/AuthzP/ASO_Introduce-Resource-Server_0.md (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 *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl