[Legal] Giving resource servers risk mitigation tools they're comfortable with, in/next to UMA
On our last subgroup call, Adrian and I agreed to do an exercise next time called “Adrian and Eve walk through attempted UMA mapping to Agency”. I thought it might be a good idea to explain in email ahead of time what the whole exercise is about. First, please note that in updating the GitHub wiki, I included a new page https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between-... that has OAuth agency-mapping work we completed on the last subgroup call. If you take a look at just the first section of this page, you’ll see the basic idea: choosing a perspective and literally mapping OAuth entities and flows to principal/agent/third party distinctions. Later in that doc you’ll see the “UMA mapping to agency” work that Adrian originally conducted, along with notes from me. Before reading on, though, it’s important to have more context. My perspective going in was: The UMA protocol today only has XYZ capabilities of expression, and no more. What I was hearing in Adrian's discussion of “an RS needs a safe harbor” was a variety of ideas about things that that sounded protocol-ish, but that I was concerned weren’t part of UMA today. So I was looking for a punch list of “technical things that still need to be developed” so that we didn’t over-promise anything. Adrian’s perspective going in was: Any operator of a service (i.e., a potential RS) that is worried about liability in handing out an individual’s data has got to protect itself, and the obvious expedient for protecting oneself is right in front of us: The example of a Release of Information (ROI) form used by healthcare providers, such as hospitals, in the US. Since healthcare is the hardest case known to humankind, and resource server operators have it the worst among all the UMA-related parties, and (I’m reading into things here) the liability situation for providers who release data is harsh in the US, if we can simply tack on the essential elements of the ROI form design pattern to UMA so that all RS’s in any vertical or sector can get the benefit (while also looking out for Alice), we’re golden. Below is a very old graphic (which can be seen in a predecessor document to the Binding Obs, the Legal Considerations in UMA Authorization http://kantarainitiative.org/confluence/display/uma/Legal+Considerations+in+...) that helps visualize the challenge. Please forgive incorrect terminology (though it occurs to me that maybe we can leverage this graphical style in conveying our Agency mappings at some point??). Just focus on the “TOS” to the left of “Host Service Vendor” (which means “RS Operator”). That agreement is basically where the ROI form slots in, at least for hospitals, and it has outsized importance because it is the main contractual device that RS Operators use to manage their liability around personal data release. Now, because we want to be looking out for Alice, it’s not enough to just think about the RS’s needs. “TOS” would normally be take-it-or-leave-it Term of Service. Could UMA do better? This is where Adrian (with his infinite faith in UMA and technology!) had dreamed up an idea for what UMA really should offer, to go beyond just the “BL” world and into the “T” world. You can see the result of our discussion (about how UMA doesn’t currently satisfy such needs) in this new GitHub issue, #224, RS Notifies AS or RO of Access https://github.com/KantaraInitiative/wg-uma/issues/224. Even without any technical changes to the UMA protocol, we did recently make explicit room for the RS risk mitigation world with spec wording (what I recently called “wormholes” in email) that now reads https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-09.html... as follows (emphasis added): “The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.4) indicates that the resource owner's policies have been met for access to the protected resource. The resource server MAY apply additional authorization controls when determining how to respond. …. The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization. To ensure the integrity of the ecosystem in which the resource server, authorization server, and resource owner are participating, it is RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level. See Section 7.4 for more information." Now, if you read the Proposal for Mapping UMA to Agency Law https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between-... section of the wiki page, you can see what Adrian was aiming at in his analysis, and we can judge its accuracy and suitability together on that basis. (My one request is that if we come up with cool things UMA could do that it doesn’t do at present, they have to go into GitHub as issues! :-) ) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
I find the diagram or table inscrutable.
I see the ROI Form as mapping into the phases of the UMA protocol as
follows:
Phase 1 - Registration: The form of the contract is presented by the
third-party to Alice. Alice introduces her Agent to help complete the
Registration phase. There is no Requesting Party or Client at this phase
but the contract can place constraints on the other parties to be
considered under the contract.
Phase 2 - Request: A specific instance of the ROI Form is created when
attributes of the RqP / Client are available to the RS and AS. The RO does
not have to be directly involved.
Phase 3 - Disclosure: The AS and the RS agree to provide access to the
protected resource and the outcome is logged by both as a specific
time-stamped instance of the ROI Form contract that can be used to settle
disputes.
Adrian
On Wed, Sep 9, 2015 at 6:12 PM, Eve Maler
On our last subgroup call, Adrian and I agreed to do an exercise next time called “Adrian and Eve walk through attempted UMA mapping to Agency”. I thought it might be a good idea to explain in email ahead of time what the whole exercise is about.
First, please note that in updating the GitHub wiki, I included a new page https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between-... that has OAuth agency-mapping work we completed on the last subgroup call. If you take a look at just the first section of this page, you’ll see the basic idea: choosing a perspective and literally mapping OAuth entities and flows to principal/agent/third party distinctions.
Later in that doc you’ll see the “UMA mapping to agency” work that Adrian originally conducted, along with notes from me. Before reading on, though, it’s important to have more context.
My perspective going in was: The UMA protocol today only has XYZ capabilities of expression, and no more. What I was hearing in Adrian's discussion of “an RS needs a safe harbor” was a variety of ideas about things that that sounded protocol-ish, but that I was concerned weren’t part of UMA today. So I was looking for a punch list of “technical things that still need to be developed” so that we didn’t over-promise anything.
Adrian’s perspective going in was: Any operator of a service (i.e., a potential RS) that is worried about liability in handing out an individual’s data has got to protect itself, and the obvious expedient for protecting oneself is right in front of us: The example of a Release of Information (ROI) form used by healthcare providers, such as hospitals, in the US. Since healthcare is the hardest case known to humankind, and resource server operators have it the worst among all the UMA-related parties, and (I’m reading into things here) the liability situation for providers who release data is harsh in the US, if we can simply tack on the essential elements of the ROI form design pattern to UMA so that all RS’s in any vertical or sector can get the benefit (while also looking out for Alice), we’re golden.
Below is a very old graphic (which can be seen in a predecessor document to the Binding Obs, the Legal Considerations in UMA Authorization http://kantarainitiative.org/confluence/display/uma/Legal+Considerations+in+...) that helps visualize the challenge. Please forgive incorrect terminology (though it occurs to me that maybe we can leverage this graphical style in conveying our Agency mappings at some point??). Just focus on the “TOS” to the left of “Host Service Vendor” (which means “RS Operator”).
That agreement is basically where the ROI form slots in, at least for hospitals, and it has outsized importance because *it is the main contractual device that RS Operators use to manage their liability around personal data release*. Now, because we want to be looking out for Alice, it’s not enough to just think about the RS’s needs. “TOS” would normally be take-it-or-leave-it Term of Service. Could UMA do better?
This is where Adrian (with his infinite faith in UMA and technology!) had dreamed up an idea for what UMA really should offer, to go beyond just the “BL” world and into the “T” world. You can see the result of our discussion (about how UMA doesn’t currently satisfy such needs) in this new GitHub issue, #224, RS Notifies AS or RO of Access https://github.com/KantaraInitiative/wg-uma/issues/224.
Even without any technical changes to the UMA protocol, we did recently make explicit room for the RS risk mitigation world with spec wording (what I recently called “wormholes” in email) that now reads https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1-2015-09-09.html... as follows (emphasis added):
*“The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.4) indicates that the resource owner's policies have been met for access to the protected resource. The resource server MAY apply additional authorization controls when determining how to respond. …. The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization. To ensure the integrity of the ecosystem in which the resource server, authorization server, and resource owner are participating, it is RECOMMENDED for the parties to establish agreements about access rules in this case on a legal or contractual level. See Section 7.4 for more information."*
Now, if you read the Proposal for Mapping UMA to Agency Law https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Mapping-Between-... section of the wiki page, you can see what Adrian was aiming at in his analysis, and we can judge its accuracy and suitability together on that basis.
(My one request is that if we come up with cool things UMA *could* do that it *doesn’t* do at present, they have to go into GitHub as issues! :-) )
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
participants (2)
-
Adrian Gropper -
Eve Maler