Sorry, my design patterns might have been a little too light on detail. Here are "user stories" that go with them:

Alice uses AS and RS for herself: She's the Authorizing Party and also the Resource Subject. She would be the one using the AS to configure who gets access, and the one using the RS to manage resources. This is sort of "normal UMA" usage.
Alice uses AS and RS as agent for son Johnny: Johnny is two years old, and he doesn't use any online services at all yet. Alice is his mom, and she manages his health data and daycare appointments as online resources. She is his legal agent because he doesn't have legal capacity. Technical challenges: Someday he'll get older and start managing resources on his own behalf. How does that transition of resources and accounts get effected?
Alice uses AS as agent for 12yo Susie; Susie uses RS herself: Susie is an older kid, but still covered under laws such as COPPA, so she doesn't have the legal capacity to consent for herself. She logs into a resource server such as an UMA-enabled webkinz.com to manage her resources, but her mom Alice is the one who logs in to the authorization server to manage access settings for her as her agent. (For a long time, we have called this a "split-RO" pattern in the WG.) ... We haven't actually figured out how to make this happen 100%, though, because if you think about the OAuth flow to issue the PAT, it counts on a singular resource owner being on both sides, and here we have two people. The actual webkinz service does require parents to have a companion account, I think, so maybe that's something we assume? (Steve G.? Are you out there?) Also, when Susie gets old enough to have legal capacity (or meets other non-age tests), how do we manage that?
Gov agency/admin uses AS and RS as agent for citizen Alice: As described on the last call, the NZ government did a proof-of-concept where they let an offline adult (who has legal capacity) set up a policy to share resources with somebody like a caregiver, or an adult son. While the caregiver etc. would be a requesting party, the government agency itself (or a human admin working as an employee of the agency -- holy recursion, Batman) is the agent of Alice in setting up a "headless" account for her, and manages it for her on an ongoing basis. Alice is sent an email when this happens, and can "claim" control of the RO account anytime she likes. You can read a brief description about it in the PDF file linked from here (search for "headless").

I hope that last one is clear. I see now how Adrian and I might have been confusing each other.

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

On Mon, Feb 15, 2016 at 8:21 PM, Eve Maler <eve@xmlgrrl.com> wrote:

Below...

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

On Fri, Feb 12, 2016 at 2:56 PM, Adrian Gropper <agropper@healthurl.com> wrote:
- Definitions:

Resource Registration Agreement - A contract between the Resource Server Operator and the resource subject or authorized agent of the resource subject that defines a resource pertaining to the resource subject, including available and supported scopes, and delegates some control over that resource to an Authorization Server. The Resource Registration Agreement establishes Phase 1 of the UMA Protocol at a time when neither the Client nor the Requesting Party are known to either the RS / RSO or the AS / ASO. As such, this is equivalent to a typical healthcare ROI form if the ROI form were to specify an agent for the subject instead of the client for for the purpose of authorized access to the resource.

This looks just about exactly like what we've been categorizing as the Resource Server Operator's aggregate set of obligations to the Authorizing Party so far, both in the old Binding Obligations spec (where the latest possible "tripping event" was PAT issuance) and in our nascent model clause work, with one big clarification. We've been saying that the RSO would make these promises generically to the Authorizing Party. You're suggesting that the Authorizing Party explicitly needs to either be the Resource Subject or acting on their behalf.

(Did you mean to say "an agent for the subject instead of the subject"? Otherwise, I'm confused.)

(I think you're overcooking some of the details here, btw. Phase 1 is certainly before a client or requesting party is required to be in the picture, technically speaking, but of course Clients and Requesting Parties may already be known to these other parties.)

(You are using "Resource Subject" below to mean something equivalent to "Data Subject" or "PII Subject", but haven't defined it apart from a longer term. Do we care which we use? What is going to be friendlier to the purposes of our customers? If it's six of one and half a dozen of another, it might actually be easiest to use this third-way term, because we can use it freely in our own UMA-related definitions, and then define the term by referencing the other two terms of art, mentioning their standards origin -- in other words, have as clean an interface between the UMA terminology world and the "outside" terminology world as possible. So for now, I've stuck with Resource Subject.)

Authorization Server Endpoint - The URI and associated .well_known endpoints of a standards-based authorization server acting as the agent of the resource subject during UMA Phase 2. Under this Resource Registration Agreement, the RSO agrees to consider a token signed by the AS as presented by the RqP / Client. The RS may either accept the token or it can notify the AS that the token was not accepted or modified in scope.

The endpoint description goes off the rails technically here, a bit. I don't think it's too useful to define technical stuff in a legal discussion; more important to focus on the legal distinctions. Here is the question I have regarding your ROI form concerns:
Are you proposing that a different Person interact with the authorization server and the resource server, so that one can be the Authorizing Party and the other can be the Resource Subject, respectively?
Resource Subject Signature and Date - The individual who's PII is accessed via the resource. This individual could be any age and should not need to be able to read or write or use technology.

And here's the next question I have regarding your ROI form concerns:
What if the Resource Subject does not have legal capacity to sign and date a form? (aha, but I think I see where you're going in the next step...)
Authorized Agent Name, Signature and Date - The individual that the RSO recognizes as an authorized agent of the resource subject in cases where the resource subject is unable to sign for herself. The basis of this recognition is completely out of band from UMA.
So if the Resource Subject does not have legal capacity, then the you're saying the Authorized Agent would become the Authorizing Party on their behalf. I agree that the basis of this recognition is a BLT thing and not part of UMA-the-protocol.

- Is this UMA?

In my subject-centered vision of UMA, the RS has no visibility into whether the Resource Subject or the Authorized Agent or anyone else is in control of the Authorization Server Endpoint. In Phase 2 or 3 of UMA, the RS can choose to take attributes of the Client and RqP into consideration along with the Token issues by the AS or the RS can accept the token as is. If the RS changes the intent of the token, either more or fewer privileges, then the RS must notify the AS of the change.

It may be that my subject-centered vision of UMA is not actually UMA. I don't know. If it's not, then we should try to give it a name because all I'm talking about is the subject's right to specify an agent by executing a Resource Registration Agreement - period.

UMA-the-protocol does not care whether the resources being protected even contain PII. :-) The resources could be sensitive by virtue of being valuable (someone wants to charge for them or someone considers them trade secrets, or whatever). But if they are both sensitive and personal, we have treated it as an important UMA use case -- if not the only UMA use case -- that the resource owner/Authorizing Party is the Resource Subject. So it's a very very good idea for our work in this subgroup to focus first and foremost on model definitions and model clauses that get this right.

This discussion is helping me get some of the use cases (or are they UMA design patterns?) swirling in my head into some kind of order. Let me try them in the attached graphic.... I've highlighted a few technical challenges there. We also have some legal definitional challenges remaining, like maybe: Authorizing Party Agent? What else?

Adrian

--

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/

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma