@Andrew - What you say is confusing to me. I'm simply saying that a natural person has a right to technology that they own and control completely in the form of an UMA AS. UMA as a protocol MUST respect that right.

The RSO can choose to respect that right or not. The RS can ignore the AS regardless of who controls it. That has nothing obviously to do with UMA as a technical protocol.

As for the "endangering other resources" point. I bring that up because in health care the patient has a right to access (That does not seem to be the case in general. I know of only one other example which is credit bureaus). When there's a right of access, the RSOs look for excuses to block their duty to grant access and, in healthcare, they try to use the excuse that patient-controlled access would endanger the security of other resources at the institution.

Adrian

On Sat, Feb 20, 2016 at 8:41 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
@Adrian
If the RSO is OK with only having proof the AS is under your control, then that should be in the legal contract.

I suspect most RSO's would want more assurances than that - but again that would go in the legal contract.

And in both cases, there would be impact on liability for damages.

UMA the technical protocol has nothing to say at all about 'endangering ' other resources . That's all up to how the RSO implemented their access control system.

On Sat, Feb 20, 2016 at 3:09 PM Adrian Gropper <agropper@healthurl.com> wrote:


On Saturday, February 20, 2016, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
@Adrian

From your description, it sounds to me that you are seeking the Operator of the Resource Server to agree to accept and use an Authorization Server that the Subject (one or more of your list of 4 possible candidates) specifies. (I think)
Yes. 

As long as the Operator of the Resource Server is willing (and I suspect that for some cases they won't be willing) to externalize authorization policy decision point functions to a (probably) previously-unencountered Authorization Server, then isn't this "simply" a case of writing a contract that specifies terms of use etc.? 
Maybe. I'm not saying that the specified AS is the only source of input into what the RS does (the so-called Adrian clause in UMA). I'm just saying that it's one input into the resource registration (Phase 1) agreement.

Perhaps there is a Discovery Service function that the Resource Server uses to find the AS and get endpoint information from the AS. 
Yes. I assume it's WebFinger (that's what Justin taught me) but it could be anything else. 

But the big thing, I think, is to satisfy the Resource Server Operator that it is 'safe' to externalize authorization policy decisions. I.e. that the AS is operated at an mutually-acceptable level to deliver reliable, trust-worthy assertions.
No. All we need to do is to satisfy the RSO that the AS is under my control. It's up to UMA as a technical protocol, to ensure that my choice for an AS does not endanger any other resource hosted by that RS. 

Am I getting closer or further away from the point?
You are much closer, particularly now that you are focused on Phase 1 and nothing more.

Adrian 

andrew.

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 


On Sat, Feb 20, 2016 at 10:10 AM, Adrian Gropper <agropper@healthurl.com> wrote:
@Andrew, the confusion arises when we try to complicate the legal agreements of Phase 1 with those of Phase 2 and later. In Phase 1, by definition, the agreements, both technical and legal, cannot be complete because UMA, by design, is meant to bind the RS and AS at a time when the client and requesting party are just not in the picture at all and therefore cannot be paerty to the Phase 1 agreement.

I propose that UMA Binding Obligations (or model contracts or whatever) be strictly separated into Phase 1 vs. Phase 2 and later. Maybe the terminology and definitions carry over across the two kinds of agreements or maybe we should not even try to share them.

There are an uncountable number of kinds of Resource Servers and Clients with APIs out there across things, industries, domains, jurisdictions, and business interests. When it comes to data (identifiable or de-identified) about a natural person, the set of kinds of authorizing parties is much smaller. It includes:
  • natural persons,
  • custodians voluntarily associated with a natural person,
  • custodians associated with the natural person by the state, and
  • entities serving the interests of multiple natural persons.
My proposal for the Phase 1 Agreement is to bind the particular resource API exposing information about a particular natural person to one or more of the 4 kinds of authorizing parties above. Each party to the Phase 1 agreement would be listed by name.

I would avoid use the term Resource Owner completely. What is a "collection of entities" when a resource refers to data about only one natural person?

I agree that the protocol Phase 1 must recognize group actions and permission delegation. That's why I propose that the Phase 1 agreement must name the authorizing parties, including groups, if any. This still has nothing to do with Phase 2 or later agreements.

Adrian


On Fri, Feb 19, 2016 at 7:59 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
The conversation is confusing to me.

Is this a case where the Resource Owner (from the protocol doc meaning) grants authority to a different entity/actor?

How do other access control systems handle delegation of permissions?

How would UMA work if the Resource Owner is not a singular entity but rather a collection of entities?

If the protocol cannot express or recognize group actions or permission delegation the talking about legal agreements is premature.
Andrew.
On Fri, Feb 19, 2016 at 4:48 PM John Wunderlich <john@wunderlich.ca> wrote:
I may be seeing in the eighth colour, and if so, please call me out of scope, and we can move on.


On Feb 19, 2016, at 16:58, Adrian Gropper <agropper@healthurl.com> wrote:

"It's turtles all the way down, madam."

I'm not saying Eve is the madam. What I am saying is that the ISO concepts of Subject, Controller, and Processor are of limited utility to UMA technical or legal.

I fled to the ISO terms because ‘agent/agency’ are too protean and I am averse to directly linking to a particular country's legal framework - even my own (Blame Canada!). I think that they are useful constructs for the discussion. And I’m hopeful that they can be used as bridge terms between the UMA technical terms and various jurisdictions’ actual legal parlance. But as I’m relatively new to the group, and if the introduction/use of these terms is getting in the way of consensus/agreement I’m happy to set these terms aside. 

As long as in real life the RS has a _direct_ relationship with the Subject (and the subject's custodian in Eve's five bullets above - whoever they are, they have credentials that the RS recognizes) the RS is both a Controller and a Processor.

The “As long as in real life…” is a massive if statement that, were we to take the stories out of health care into another context but kept the same patterns, might not be so self evident - employee/employer, government/citizen, and so on. And Eve has already shared a working solution for one of those cases. 

 If we’re using the ISO definitions Controller and Processor are mutually exclusive roles. Here are the actual definitions from the standard. You will see that there are is only one subject, only one controller, and after that its processors all the way down - acting on instructions.

PII controller: privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes 

NOTE A PII controller sometimes instructs others (e.g., PII processors) to process PII on its behalf while the responsibility for the processing remains with the PII controller.

PII processor: privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII controller 

PII principal: natural person to whom the personally identifiable information (PII) relates 

NOTE Depending on the jurisdiction and the particular data protection and privacy legislation, the synonym “data subject” can also be used instead of the term “PII principal”.


For example, a subject or custodian can present to the RS and nullify or amend the resource registration agreement representing UMA Phase 1. With the right credentials, the AS may not even be notified - as when the FBI presents a court order to Apple :-)

The AS in real life is also both a Controller and Processor. As a policy driven authority in Phase 2 it's just a processor. In Phase 1, when the resource authority (subject, custodian, whatever) is signed-in to the AS, the AS is a controller. This is where the "turtles all the way down" comes in. As soon as UMA technical or legal chooses to put the AS policies or actions under the control of someone _in addition to_ the resource authority, the resource authority can turn the AS into an RS and set up an agreement that points to an AS (the next turtle) that really is owned and controlled by the resource authority.

To map this to current events, Apple's iPhone 7 can introduce an UMA AS with a secure policy store that self-destructs if the credentials are mismanaged. That would meet my definition of an owned UMA AS and it's what I'm building as HIE of One. Is it the first turtle, or the last?

Adrian





On Fri, Feb 19, 2016 at 12:15 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes

2016-02-19

  • Distinguishing resource subjects from resource owners: Can we develop a cohesive system whereby "resource subjects" without legal capacity can have "authorized agents" acting on their behalf as "resource owners" as required in order to forge "resource registration agreements" for the purpose of UMA's phase 1 particulars? Do the use cases/design patterns provide any insights or challenges here?

Attending: Eve, Andrew Hughes, Paul L, John, Ann, Adrian, Jon, Kathleen, Sal

Is it valuable to solve for a model where an agent can be working on behalf of resource owner vs. a resource owner?

The protean nature of the word "agent/agency" is troubling. Is there a good substitute word? If not, do we have to define *Agent for all of our terms in an UMA context? We did already have Requesting Party Agent. Perhaps, at best, we should define it operationally but stay away from legal subtleties.

We've said that resource owner = Authorizing Party. Does that work, or is it not equivalent? There are terminology questions and there are UMA architecture questions. Should we just wave away problems by making them equivalent?

  • 1yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a one-year-old kid and their mom has to manage the resources by logging in to the RS? The child is not competent to contract, even if they're old enough to sign their name. Guardian is a good name for the latter.
  • 12yo case: What if the "resource owner" (let's say they're the "subject" of the data residing in the RS) is a 12-year-old kid and they're old enough to manage the resources by logging in to the RS themselves? The child is not competent to contract, even if they're old enough to manage resources online. How to architect the system and name the parties?
  • Intermittently competent adult case: This is another tough one.
  • Competent adult case: What if the "resource owner" (let's say again that they're the "subject" of the data residing in the RS) is actually competent to contract, but wants to have someone else manage resources for them online? There's a paper resource owner, but an online "executor" of resource management. What's a good term?
  • Digital death case: After the "resource owner"...

Adrian's concern is what happens in phase 1. These use cases have different properties in that phase. Eventually (soon), we will be in a position to work on what's supposed to happen when RS's want to take an action in response to an access request that is in contradiction to the permissions contained in an RPT (requesting party token). First, we need to understand exactly "who" configured the AS to 

By the way, all the same patterns could apply whether or not the resources contain PII or not. What if the resource owner created digital media that they want to sell? Is there a reason to distinguish in our terminology at all? What if a resource contains PII "in bulk" for many individuals (in directories or databases or other repositories)? This was the point of Adrian's example. Eve's point was, rather, that individuals might want to be protecting resources that don't contain PII. Okay, now we're on the same page! There are use cases for UMA that span "Alice" and "enterprise".

Let's try to conclude this decision-making process by next week, and then move on to the decisions about RS actions in contradiction.


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/
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma



This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
--

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 




--

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/

--

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 




--

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/