Regarding candidate duty D, I wonder if it might be better stated the other way around (it's the RSO that has the duty) until we have a technical endpoint available for the AS (or maybe someone else also/instead?) to expose. As noted under candidate duty B, rather than have the RSO "respect the permissions" 100%, more likely it would be something like the RSO has a matrix of duties that looks like our list from our Jan 15 meeting notes, only with the conditions filled in, and with the method of notification hopefully prescribed in some fashion.


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Fri, Apr 1, 2016 at 9:00 AM, Adrian Gropper <agropper@healthurl.com> wrote:
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. 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/