Your crystal ball about the ecosystem pressures may or may not be right... But "my technology" could include "my shoebox endpoint" even if it lives outside "my AS". It's not entirely clear yet that this endpoint (which doesn't exist yet) is part of an API that should inextricably be bound up with an UMA protection API vs. the API of some other kinds of service(s).

FWIW, I get a ton of use out of registering one or more email addresses from/to which I can forward various kinds of invoices, receipts, and other artifacts; it works great with today's technology, and it doesn't seem to be "disempowering" (you can use it with IFTTT and other lightweight business process management "recipe" tech). Why couldn't email be one very successful design pattern for notification?


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


On Tue, Apr 12, 2016 at 11:14 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Making it an ASO duty is critical to UMA adoption. If we don't provide the notification endpoint at the ASO, the RSO will simply ask for an email address or something and ignore UMA in favor of a tightly bound AS. This is the camel's nose under the tent because it's harder to block arbitrary notification endpoints than it is to block arbitrary authorization endpoints. In other words, I want my notifications sent to my technology even if you say I have no power to control authorization at all.

Adrian



On Tue, Apr 12, 2016 at 1:27 PM, Eve Maler <eve@xmlgrrl.com> wrote:
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/




--

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/