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
