Thank you, Jim. I think this is what I was trying to say, much less coherently, when I suggested that the generic RSO - ASO agreement was trivial. Adrian On Saturday, March 26, 2016, James Hazard <james.g.hazard@gmail.com> wrote:

One small point with perhaps important impact on the mechanics of the text:

Having clarified that Authorizing Party can be bifurcated into Resource Subject and Grantor, we then have the issue of to whom the duties of others should "run" - as we say in law.

Eve: "Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases."

We could either:

i) work this through and in each Clause appropriately reference:

a) Resource Subject, b) Grantor, or c) : a) and b).

ii) make all references be to Grantor, and provide (somewhere) generally that duties owed to Grantor run to the benefit of Resource Subject. As always, IAMAL and not an expert ... but this seems more robust and flexible. Familiar to the law via the agency notion of a disclosed principal.

Cheers, Jim

On Fri, Mar 25, 2016 at 5:45 PM, Eve Maler <eve@xmlgrrl.com <javascript:_e(%7B%7D,'cvml','eve@xmlgrrl.com');>> wrote:

...

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... 2016-03-25

- Review current set of model definitions - Choose first trust relationship to work on for model clauses - Identify any model definition areas that need work given our choice - Decide/confirm our plan for first round of external review

Attending: Eve, Paul, Kathleen, Adrian, Jon N, Ann, Jim

We reviewed our model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/> with model definitions <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/Terminology/Terms_0.md>, with recent changes.

What's the deal with the "D word" – delegation? If we qualify "delegation of *what*", then we can observe that there are several types, and we can map them to different trust relationships we have identified:

- Resource Subject - Grantor (not in scope): This enables a "resource owner" to find someone else to actively manage resource access for them at an AS. - Grantor - ASO: This enables an always-on AS to be available to execute the wishes (policy conditions) of the Grantor. - RqP - Client Operator (not in scope; also not previously discussed as a model definition...) - Grantor - RqP

Discussion about Grantor - RqP: Adrian doesn't think this is an appropriate use of the word "delegation". Eve believes "that train has sailed". [image: (smile)] See, e.g., the NZ POC <http://kantarainitiative.org/confluence/display/uma/Case+Study%3A+Users+Managing+Delegated+Access+to+Online+Government+Services> .

Regarding Adrian likes the distinction of "If you have a privacy policy, then there's an Operator involved; if you don't have a privacy policy, then you own it/wrote it." (It's personal to you and there's a 1:1 relationship between you and the software/service.)

We have a new party with responsibilities now in scope! It's the Client Operator.

Also, we're likely going to have to change references in the bodies of various model clauses from the Grantor to the Resource Subject, since the duty will be owed to the Resource Subject instead in a lot of cases.

Which trust relationship should we dig into first? For reasons of our #RSctrl/#ROctrl use case <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> tension, and because it's the most "upstream" (no dependencies) trust relationship, let's start from RSO - ASO (see the clauses that start ASO... here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/> and the clause that starts with RSO here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/UMA-Text/Clause/ASO/> – however, these are old and almost certainly don't reflect our latest discussion).

There's a use case that could help us interestingly when we get to working on Resource Subject- and Grantor-involved model clauses, but will need to take into account some out-of-band machinations because it engages precisely the Resource Subject - Grantor relationship: a "digital death" use case. Alice (as her own Grantor) shares some digital data resources with Bob. She wants to arrange for her lawyer to become her Grantor when she dies, so that Bob can continue to get access to those resources. In practice, because of what are known (really) as "time-to-live" strategies around credentials, tokens, and permissions inside tokens, the access that Bob enjoys to those resources is certain to get cut off at some point after Alice dies. Using a combination of business, legal, and (non-UMA – including digital contract) technical approaches, Alice's lawyer can replace Alice as the owner of those resources and ensure through the AS that Bob's access can continue or be restarted.

*AI:* Jim and Eve: Extract the two-party reworkings of the old model clauses for at least RSO - ASO and prepare for group review next week.

*AI:* Everyone: Think about and approach candidate external reviewers by next week.

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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','WG-UMA@kantarainitiative.org');> http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

-- 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/