http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes... 2017-06-30 Attending: Eve, Tim, Kathleen, John W, Bjorn, Colin, Mark L, Sal, Mary Let's clarify all our role terms and concepts today: 1. *Resource Owner** (was Grantor)* 1. *Data Subject* *(was Resource Subject)* (has privacy framework meaning) - could be the Resource Owner or has delegated authority to a separate Resource Owner by law or contract 2. *Authorization Server Operator* - Agent (fiduciary?) of the Resource Owner - role is controlled by the PAT, and in practice it issues the end-to-end licenses because it issues the RPTs 3. *Resource Server Operator* - Data Controller (has privacy framework meaning) - is the Resource Server Operator 4. *Client Operator* - 1st-tier Data Processor (has privacy framework meaning) - is always the Client Operator? or if the Resource Owner grants access in order to make the Requesting Party be another Data Controller, what does that make the Client Operator in this case? 5. *Requesting Party* - 2nd-tier Data Processor (has privacy framework meaning) - is always the Requesting Party? - or maybe the Resource Owner wants to make the Requesting Party be another Data Controller? 1. *Access Beneficiary*??? - a party that the Requesting Party is acting on behalf of, either themselves or another party - a better name for this? We definitely don't like the word "ownership" of data or records. Is there licensing of data, or a record, or what? Since the access grant could be about disclosure of data, or deletion of data, or execution of an algorithm, or whatever, the licensing similarly could be sophisticated. It could specify that the recipient gets a copy of the data, etc. We want to have a concordance between all of these roles and the UMA flow. Do we use the role terms *Licensor* and *Licensee* at different points in our clause text vs. the terms above? Or can we punt on that for now? E.g., maybe the Resource Owner becomes (dons a role of) a Licensor at a certain point in a contract, and a Requesting Party becomes a Licensee. Two of the parties listed above would be parties to the license/contract, and others are subsidiary. But we still need to complete our mapping work to understand the precise relationships of them all, wrt UMA. The Resource Owner is the one that has to hire/contract with the ASO, because it can't be someone who doesn't have legal capacity etc. Or even if the Data Subject contracted with some agent, say, an attorney, to take care of financial business or whatever for them, then that Resource Owner really does function as their delegated agent and contracts with the ASO on their behalf. Of course, just as in Google Docs, the agent might need to "transfer ownership" of resources back to the data subject at some point – and the IRM group's design guidelines include just such actions! Delegable, Transferable, etc. This justifies our "indenting" the Data Subject role; it's "offline" wrt UMA, and our model. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl