Re: [WG-UMA] [wg-uma] What deliverables should the UMA Legal subgroup provide? (#180)
I think the most important deliverable is a clear explanation and demonstration of how implementing UMA will provide the Resource Server institution increased cybersecurity and a safe harbor for exposing an interface to the public Internet. Although many of us are mostly motivated by other goals including consumer protection and the hope of selling software to the operators of authorization servers, these will not drive adoption of UMA without new laws and regulations. Let's see how far we can get with the current laws. To this end, Dazza has provided a wonderful document about Restatement of Agency Law <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf>. I've tried to map the essential elements of Agency: Principal, Agent, and Third Party into a very simple document https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_... that is open for discussion and editing. Eve and I had a very long session trying to understand the gaps between the Agency Law and UMA. These gaps are represented in the table toward the end of the Gdocument. I think that mapping UMA to Agency Law is more important and easier than standardizing or formalizing Terms of Use and Privacy Policies. To the extent that we can map UMA to Agency Law without introducing any specific profiling for healthcare, education, or any other vertical domain, we will be doing the best job of promoting adoption of UMA for the benefit of the RSs, the ROs, and the AS business. Adrian On Wed, Sep 2, 2015 at 1:11 PM, Dazza Greenwood <notifications@github.com> wrote:
In conversations during the Legal subgroup meetings, some people have suggested including example, sample or "standard" legal wording for ToS and other legal instruments for use with UMA deployments. Not yet sure what those would say, but it would be a sign of success to get to the point of recommending such terms. If the subgroup deliverables includes both recommended terms and an approach to audit logs for legal compliance or enforceability, we would have a strong set of deliverables.
— Reply to this email directly or view it on GitHub <https://github.com/KantaraInitiative/wg-uma/issues/180#issuecomment-137174779> .
-- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
The nominations for Legal Subgroup deliverables so far (just in the order received): * Recommendations for how to make audit logs usable tools for legal compliance/enforcement * Some example legal provisions one would expect to see at key moments * Mapping between UMA and Agency Law The Agency Law mapping could serve to achieve all three, because the process necessarily includes reference to the contractual terms, if any, applicable among the parties and also surfaces how evidence is created and preserved and will highlight what evidence is most relevant (hence we will hit the issues/options for priority log data and other business records). We should take care to avoid advocating the interests of parties responsible for Resource Servers above other parties in other roles. We can and should identify the need for prioritizing adoptability by parties responsible for Resource Servers and also identify and address the needs of the other key parties. A more neutral multi-vantage-point Agency Law analysis can provide voice to deep expectations and motivations of UMA-using parties in relationships with each other. Humans are social animals and we should use agency to see how UMA can enhance existing (or create new) mutually beneficial key relationships, fueled by the proposition of greater economic and other value for all key players. I suggest sustained adoption could be better served by taking a generally neutral stance and affording due priority and respect for the interests/needs of all players, including OAuth 2 Client and Authorization Server providers, definitely the Principal Individuals and also Resource Server providers. Thanks, - Dazza _ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza@CIVICS.com | Biz: http://CIVICS.com | MIT: https://law.MIT.edu | Me: DazzaGreenwood.com | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _ On Wed, Sep 2, 2015 at 2:04 PM, Adrian Gropper <agropper@healthurl.com> wrote:
I think the most important deliverable is a clear explanation and demonstration of how implementing UMA will provide the Resource Server institution increased cybersecurity and a safe harbor for exposing an interface to the public Internet. Although many of us are mostly motivated by other goals including consumer protection and the hope of selling software to the operators of authorization servers, these will not drive adoption of UMA without new laws and regulations. Let's see how far we can get with the current laws.
To this end, Dazza has provided a wonderful document about Restatement of Agency Law <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf>.
I've tried to map the essential elements of Agency: Principal, Agent, and Third Party into a very simple document https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_... that is open for discussion and editing.
Eve and I had a very long session trying to understand the gaps between the Agency Law and UMA. These gaps are represented in the table toward the end of the Gdocument.
I think that mapping UMA to Agency Law is more important and easier than standardizing or formalizing Terms of Use and Privacy Policies. To the extent that we can map UMA to Agency Law without introducing any specific profiling for healthcare, education, or any other vertical domain, we will be doing the best job of promoting adoption of UMA for the benefit of the RSs, the ROs, and the AS business.
Adrian
On Wed, Sep 2, 2015 at 1:11 PM, Dazza Greenwood <notifications@github.com> wrote:
In conversations during the Legal subgroup meetings, some people have suggested including example, sample or "standard" legal wording for ToS and other legal instruments for use with UMA deployments. Not yet sure what those would say, but it would be a sign of success to get to the point of recommending such terms. If the subgroup deliverables includes both recommended terms and an approach to audit logs for legal compliance or enforceability, we would have a strong set of deliverables.
— Reply to this email directly or view it on GitHub <https://github.com/KantaraInitiative/wg-uma/issues/180#issuecomment-137174779> .
--
Adrian Gropper MD
RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
Hi Adrian, Ah yes, I should keep up with my reading.
On 2 Sep 2015, at 14:04, Adrian Gropper <agropper@healthurl.com <mailto:agropper@healthurl.com>> wrote:
I think the most important deliverable is a clear explanation and demonstration of how implementing UMA will provide the Resource Server institution increased cybersecurity and a safe harbor for exposing an interface to the public Internet. Although many of us are mostly motivated by other goals including consumer protection and the hope of selling software to the operators of authorization servers, these will not drive adoption of UMA without new laws and regulations. Let's see how far we can get with the current laws.
To this end, Dazza has provided a wonderful document about Restatement of Agency Law <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf>.
I've tried to map the essential elements of Agency: Principal, Agent, and Third Party into a very simple document https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_... <https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_vM0/edit> that is open for discussion and editing.
Eve and I had a very long session trying to understand the gaps between the Agency Law and UMA. These gaps are represented in the table toward the end of the Gdocument.
I think that mapping UMA to Agency Law is more important and easier than standardizing or formalizing Terms of Use and Privacy Policies. To the extent that we can map UMA to Agency Law without introducing any specific profiling for healthcare, education, or any other vertical domain, we will be doing the best job of promoting adoption of UMA for the benefit of the RSs, the ROs, and the AS business..
The MVCR work is based only on existing law and not dependant on any new law, I seem to have mis-represented this.. The consent receipt is only a format for recording and logging consents/authorisations, i.e. a format for capturing the agency, regardless of the policy as these consent requirements that are already in law. i.e. required. How Agency is represented is very interesting and I think a different but very related topic of liability which a record is just a piece of. (AKA UMA FLAVOUR) The provision of a standard consent notice system is a way to transfer the liability around, its more of a vehicle for Agency rather than the way to define Agency. Apologies for confusing these issues if I have Dazza seems to be able to unpack these very well and these seem to need to be unpacked more. Purpose specification is more a micro focus on HOW an UMA purpose might best be represented. I think the focus with the mapping WHAT would be in it is important and will have an effect on the way in which policy is formulated and innovated. - Mark
Adrian
On Wed, Sep 2, 2015 at 1:11 PM, Dazza Greenwood <notifications@github.com <mailto:notifications@github.com>> wrote: In conversations during the Legal subgroup meetings, some people have suggested including example, sample or "standard" legal wording for ToS and other legal instruments for use with UMA deployments. Not yet sure what those would say, but it would be a sign of success to get to the point of recommending such terms. If the subgroup deliverables includes both recommended terms and an approach to audit logs for legal compliance or enforceability, we would have a strong set of deliverables.
— Reply to this email directly or view it on GitHub <https://github.com/KantaraInitiative/wg-uma/issues/180#issuecomment-137174779>.
--
Adrian Gropper MD
RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma
I seem to have been less than clear in my point about UMA as Agency Law. The Resource Servers hold all of the cards for adoption of UMA. To pretend otherwise is wishful thinking or a deep faith in regulation of technology. To drive this point home, I would add two more points to the UMA as Restatement of Agency: - The Third Party (UMA-RS) that registers an Agent (UMA-AS) deserves a Payment (8.14) to offset their cost in offering the API and their opportunity cost of foregoing the branding and advertising benefits of a manual Web portal that would otherwise tax the Principal's attention. - The Third Party is encouraged to provide a choice of Agents for Principals that don't already have one. The Agent can be changed by the Principal at any later time. This is not required by Agency Law but it would provide a large incentive for RSs to adopt UMA before someone else does. Finally, to Mark's point, I did not mean to imply anything about MVCR. My perception of MVCR and UMA is that they are pretty much the same thing and that we are doing ourselves a dis-service by keeping them at all separate. Adrian On Wed, Sep 2, 2015 at 5:51 PM, Mark Lizar <mark@smartspecies.com> wrote:
Hi Adrian,
Ah yes, I should keep up with my reading.
On 2 Sep 2015, at 14:04, Adrian Gropper <agropper@healthurl.com> wrote:
I think the most important deliverable is a clear explanation and demonstration of how implementing UMA will provide the Resource Server institution increased cybersecurity and a safe harbor for exposing an interface to the public Internet. Although many of us are mostly motivated by other goals including consumer protection and the hope of selling software to the operators of authorization servers, these will not drive adoption of UMA without new laws and regulations. Let's see how far we can get with the current laws.
To this end, Dazza has provided a wonderful document about Restatement of Agency Law <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf>.
I've tried to map the essential elements of Agency: Principal, Agent, and Third Party into a very simple document https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_... that is open for discussion and editing.
Eve and I had a very long session trying to understand the gaps between the Agency Law and UMA. These gaps are represented in the table toward the end of the Gdocument.
I think that mapping UMA to Agency Law is more important and easier than standardizing or formalizing Terms of Use and Privacy Policies. To the extent that we can map UMA to Agency Law without introducing any specific profiling for healthcare, education, or any other vertical domain, we will be doing the best job of promoting adoption of UMA for the benefit of the RSs, the ROs, and the AS business..
The MVCR work is based only on existing law and not dependant on any new law, I seem to have mis-represented this.. The consent receipt is only a format for recording and logging consents/authorisations, i.e. a format for capturing the agency, regardless of the policy as these consent requirements that are already in law. i.e. required.
How Agency is represented is very interesting and I think a different but very related topic of liability which a record is just a piece of. (AKA UMA FLAVOUR) The provision of a standard consent notice system is a way to transfer the liability around, its more of a vehicle for Agency rather than the way to define Agency. Apologies for confusing these issues if I have Dazza seems to be able to unpack these very well and these seem to need to be unpacked more.
Purpose specification is more a micro focus on HOW an UMA purpose might best be represented. I think the focus with the mapping WHAT would be in it is important and will have an effect on the way in which policy is formulated and innovated.
- Mark
Adrian
On Wed, Sep 2, 2015 at 1:11 PM, Dazza Greenwood <notifications@github.com> wrote:
In conversations during the Legal subgroup meetings, some people have suggested including example, sample or "standard" legal wording for ToS and other legal instruments for use with UMA deployments. Not yet sure what those would say, but it would be a sign of success to get to the point of recommending such terms. If the subgroup deliverables includes both recommended terms and an approach to audit logs for legal compliance or enforceability, we would have a strong set of deliverables.
— Reply to this email directly or view it on GitHub <https://github.com/KantaraInitiative/wg-uma/issues/180#issuecomment-137174779> .
--
Adrian Gropper MD
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
-- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
Okay, one last response from me for the night — tomorrow morning it’s time to switch to “spec mode”. Excerpting heavily again:
On 2 Sep 2015, at 5:08 PM, Adrian Gropper <agropper@healthurl.com> wrote:
I seem to have been less than clear in my point about UMA as Agency Law.
The Resource Servers hold all of the cards for adoption of UMA. To pretend otherwise is wishful thinking or a deep faith in regulation of technology.
My POV: It's reasonable for us to be non-neutral on the point of which transactional relationships to focus on more heavily. Some relationships are more fraught, or more misaligned in terms of interests, than others, and being use-case based is helpful. It’s no accident that we ended up mentioning two specific pairwise relationships in the legal subgroup mission statement out of all the possible ones: Alice-and-Bob (the end-to-end sharing relationship UMA exists to make possible), and service-and-hub (that is, RS-and-AS). It’s becoming a truism, but I’ll point out again that the RS in access federation is in much the same position as the RP in identity federation: likely reluctant to lose control, concerned about liability, and somewhat disbelieving that such a job could be "outsourced to the cloud”...
To drive this point home, I would add two more points to the UMA as Restatement of Agency:
- The Third Party (UMA-RS) that registers an Agent (UMA-AS) deserves a Payment (8.14) to offset their cost in offering the API and their opportunity cost of foregoing the branding and advertising benefits of a manual Web portal that would otherwise tax the Principal's attention.
- The Third Party is encouraged to provide a choice of Agents for Principals that don't already have one. The Agent can be changed by the Principal at any later time. This is not required by Agency Law but it would provide a large incentive for RSs to adopt UMA before someone else does.
(The meeting Adrian and I had yesterday was extremely valuable, and I encourage folks — especially the DoLs <http://collectivenouns.net/disputation-of-lawyers/> — to check out the resulting document <https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_vM0/edit>.) I haven’t read the original source that you're analyzing here, so I’ll take your word for it on the citations and detail, but I like the direction of #1. (I’m not sure that “the branding and advertising benefits of a manual Web portal” need be given up totally.) #2 seems kind of specific.
Finally, to Mark's point, I did not mean to imply anything about MVCR. My perception of MVCR and UMA is that they are pretty much the same thing and that we are doing ourselves a dis-service by keeping them at all separate.
MVCR has benefits in today’s world (e.g. when Alice uses a random website) even sans UMA, and UMA has benefits even sans MVCR. But together they can be awesomesauce. Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
participants (4)
-
Adrian Gropper -
Dazza Greenwood -
Eve Maler -
Mark Lizar