Candidate duty D: "ASO-Provide-Notification-Endpoint" ...to enable the RSO to act in good faith when exceptions to Candidate Duty B are encountered in either Phase 1, 2, or 3 of UMA. Adrian On Fri, Apr 1, 2016 at 12:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
We agreed to start with the RSO - ASO trust relationship because it's most "upstream" and has no dependencies. It also turns out to be one of the most simple, at least in terms of previously brainstormed obligations/clauses. Below, I've taken the original obligations/duties and revised and commented on them given recent conversations. Let's discuss tomorrow.
====
*Condition applying to all:* For the period that the {Resource_Server_Operator} and {Authorization_Server_Operator} have mutually agreed to serve in these respective roles for each other…
*Candidate duty A.* “RSO-Register-Accurately-and-Timely” …the RSO gains an obligation to the ASO to register resource set descriptions accurately and timely.
Q A1. Do we have to qualify the wording above any further (given that we haven’t reached “Resource Subject/Grantor mention stage” yet) to talk about which resource set descriptions need to be registered? Note that there is no obligation for any RS to give any Grantor a choice about which resources to put under/take out of AS protection etc. It’s actually totally up to the RS.
*Candidate duty B.* “RSO-Respect-Permissions” …the RSO gains an obligation to the ASO to respect the permissions that the AS associates with “bearer”-type RPTs when such RPTs are later borne to the RS by Clients.
Q B1. This gets to the heart of our #RSctrl issue, as represented by the decision tree in these January meeting notes <http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes#UMAlegalsubgroupnotes-2016-01-15>. Do we need to rejigger this so that it is a) finer-grained and/or b) per-Resource Subject or on a case-by-case basis vs. per-ASO? Note that this a matter for ASO liability, as much as for Resource Subject concern, so this trust relationship does need to bear some of the weight. Much work to do here!
Q B2. The “bearer”-type token profile is mentioned specifically because each token profile comes with its own distribution of policy decision-making responsibility between RS and AS. Does this make sense?
*Candidate duty C.* “ASO-Elevate-Trust-Accurately” …the ASO gains an obligation to the RSO to perform trust elevation accurately and represent the results of trust elevation accurately in permissions in “bearer”-type RPTs.
Q C1. This is the reciprocal liability duty that the ASO carries regarding the RSO. Does that make sense?
====
What other clauses might make sense to add?
====
The theory is that if we get the RSO - ASO clauses right, then these would all be prerequisite for the next two batches, Grantor - ASO and Grantor - RSO.
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/