I'm confused. How is my UMA Authorization Server supposed to use the Privacy Policies and Terms of Service? Are we assuming some highly standardized data model around some 50 aspects of what Facebook might or might not do with my data before UMA can work? The degree of domain and business specificity that this approach implies seems totally impractical. I see service provider assertions such as Privacy Policy and Terms of Service as secondary to UMA, to be considered off line at the time when the RO either registers an AS with an RS or walks away. These policies will also enter into dispute resolution. The only link between these policies and the AS could be that the RS must specify which of the 50 clauses applies to a specific transaction to be authorized by the AS. In most cases, this metadata would not be "understood" by the AS but it would be part of the transaction logs. Occasionally, it could be linked by the RO to specific AS behavior as a kind of exception. For example, I might configure my AS to reject authorizations bearing the Facebook Policy Tag 7g without any particular standard or policy calculus.

From my perspective, the principal role of my AS is to introduce convenient _centalized_ transparency and notice into the data use practices of my service providers along with an opportunity to occasionally opt out of a transaction.

Adrian On Wednesday, September 30, 2015, James Hazard javascript:_e(%7B%7D,'cvml','jh@hazardj.com');> wrote:

One of the Facebook documents and one of the Twitter documents are now in component form. On the Facebook doc, there are some names for section components, positing a taxonomy. These names (mostly verbs) are simply a guess, and non-exclusive (the same materials can be recombined using different names). But, IMHO, evocative. In any event, a starting point.

http://cmacc-uma.herokuapp.com/index.php?action=source&file=/Wx/com/facebook/developers/policy/Form/Doc_v01.md

Both docs live in this tree: http://cmacc-uma.herokuapp.com/index.php?action=list&file=/Wx/com/

A theory of such trees is at: http://new.commonaccord.org/index.php?action=list&file=/

On Tue, Sep 29, 2015 at 5:03 AM, Eve Maler wrote:

...

I started collecting a few of these here:

https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Term...

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 PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Very briefly: UMA the technology rests on OAuth the technology. A central benefit of OAuth the technology is that is distinguishes the identity of a client application from the identity of the user of that client application (by having an AS issue credentials to a client). Accordingly, an UMA AS (in the role of an OAuth AS) needs to issue client credentials to both an UMA RS and an UMA client (each in the role of an OAuth client). We have existence proofs of business agreements hinging on the issuance of OAuth client credentials. We have decided to examine those agreements for hints of interesting elements that we may want to include in UMA legal tools/rules at a similar level. By no means do we need to feel constrained by what’s in any one of these exemplars. Eve

On 30 Sep 2015, at 8:29 AM, Adrian Gropper wrote:

I'm confused. How is my UMA Authorization Server supposed to use the Privacy Policies and Terms of Service? Are we assuming some highly standardized data model around some 50 aspects of what Facebook might or might not do with my data before UMA can work? The degree of domain and business specificity that this approach implies seems totally impractical.

I see service provider assertions such as Privacy Policy and Terms of Service as secondary to UMA, to be considered off line at the time when the RO either registers an AS with an RS or walks away. These policies will also enter into dispute resolution.

The only link between these policies and the AS could be that the RS must specify which of the 50 clauses applies to a specific transaction to be authorized by the AS. In most cases, this metadata would not be "understood" by the AS but it would be part of the transaction logs. Occasionally, it could be linked by the RO to specific AS behavior as a kind of exception. For example, I might configure my AS to reject authorizations bearing the Facebook Policy Tag 7g without any particular standard or policy calculus.

From my perspective, the principal role of my AS is to introduce convenient _centalized_ transparency and notice into the data use practices of my service providers along with an opportunity to occasionally opt out of a transaction.

Adrian

On Wednesday, September 30, 2015, James Hazard javascript:_e(%7B%7D,'cvml','jh@hazardj.com');> wrote: One of the Facebook documents and one of the Twitter documents are now in component form. On the Facebook doc, there are some names for section components, positing a taxonomy. These names (mostly verbs) are simply a guess, and non-exclusive (the same materials can be recombined using different names). But, IMHO, evocative. In any event, a starting point.

http://cmacc-uma.herokuapp.com/index.php?action=source&file=/Wx/com/facebook/developers/policy/Form/Doc_v01.md http://cmacc-uma.herokuapp.com/index.php?action=source&file=/Wx/com/facebook/developers/policy/Form/Doc_v01.md

Both docs live in this tree: http://cmacc-uma.herokuapp.com/index.php?action=list&file=/Wx/com/ http://cmacc-uma.herokuapp.com/index.php?action=list&file=/Wx/com/

A theory of such trees is at: http://new.commonaccord.org/index.php?action=list&file=/ http://new.commonaccord.org/index.php?action=list&file=/

On Tue, Sep 29, 2015 at 5:03 AM, Eve Maler > wrote: I started collecting a few of these here:

https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Term... https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Term...

Eve Maler | cell +1 425.345.6756 tel:%2B1%20425.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 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/ http://patientprivacyrights.org/donate-2/

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

I'm not trying to shut out any particular discussion. I sense that UMA can be profiled as either domain-specific or person-specific. I propose that an UMA that's person-specific will be more valuable than one that's domain-specific. Reviewing Eve's list: - UMA the technology rests on OAuth the technology. - OAuth seems to work without domain-specific "profiles". - A central benefit of OAuth the technology is that is distinguishes the identity of a client application from the identity of the user of that client application (by having an AS issue credentials to a client). - Exactly. Identity is not domain-specific. - Accordingly, an UMA AS (in the role of an OAuth AS) needs to issue client credentials to both an UMA RS and an UMA client (each in the role of an OAuth client). - Ideally, this could be done without domain-specific modifications to the AS - We have existence proofs of business agreements hinging on the issuance of OAuth client credentials. - I'm not sure what this means relative to the ability of an AS to work across vertical domains without modification. - We have decided to examine those agreements for hints of interesting elements that we may want to include in UMA legal tools/rules at a similar level. - Agreed. It seems very helpful to include references to specific policies and clauses in the information provided by the Client (and RS) to the AS. This should not mean that these references have to be in a standard format or otherwise computable by the AS. Adrian On Wed, Sep 30, 2015 at 2:30 PM, Dazza Greenwood wrote:

Adrian - all,

I had the same understanding as Eve. And I'm confident the exercise is of good relevance, small effort and high value.

Given the group is "legal" it may be worth mentioning the role of using existing documents of prior similar work in the law. Precedent is a literal part of the common law and can sometimes result in mandatory continued use of specific phrases or formats. Even when a prior artifact has no direct authority to bind later actions (such as an example prior contract by other parties to a different but similar transaction). In short - we are a profession of enthusiastic re-users of content to put it politely (sometimes regarded as shameless plagiarizers). In this instance, we are just collecting examples of existing somewhat similar legal instruments as one prong of developing a framework to move forward. As a bridge to something more familiar, you could consider this prong of activity comparable to what you did to select the hospital consent doc which you then were able to use for several purposes. The people who wrote and use that consent doc operate in a non-uma context and do not currently understand or reflect uma assumptions in their documents and workflows. Nonetheless, I think you found much value could be extracted from that prior legal instrument.

So, in short, the wiki page where we are collecting legal instruments (terms and conditions mostly at this point) demonstrates examples of what people use in related contexts. We can use these inputs identify the "gap" between explicit evidence of existing practices and what could be retained vs what would need to be modified in legal agreements in order for these companies and governments to successfully migrate to uma. The general parameters of the mission statement do not articulate objective goals or metrics of a desired end-state contracts (eg: cap liability to actual damages for party X. ensure breach notice duty for party N). However, I hope looking at one type of relevant and existing agreements can help surface some aspect of what this group believes the uma legal layer should require, allow or prohibit.

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 30, 2015 at 1:09 PM, Eve Maler wrote:

...

Very briefly:

- UMA the technology rests on OAuth the technology. - A central benefit of OAuth the technology is that is distinguishes the identity of a client application from the identity of the user of that client application (by having an AS issue credentials to a client). - Accordingly, an UMA AS (in the role of an OAuth AS) needs to issue client credentials to both an UMA RS and an UMA client (each in the role of an OAuth client). - We have existence proofs of business agreements hinging on the issuance of OAuth client credentials. - We have decided to examine those agreements for hints of interesting elements that we may want to include in UMA legal tools/rules at a similar level.

By no means do we need to feel constrained by what’s in any one of these exemplars.

Eve

On 30 Sep 2015, at 8:29 AM, Adrian Gropper wrote:

I'm confused. How is my UMA Authorization Server supposed to use the Privacy Policies and Terms of Service? Are we assuming some highly standardized data model around some 50 aspects of what Facebook might or might not do with my data before UMA can work? The degree of domain and business specificity that this approach implies seems totally impractical.

I see service provider assertions such as Privacy Policy and Terms of Service as secondary to UMA, to be considered off line at the time when the RO either registers an AS with an RS or walks away. These policies will also enter into dispute resolution.

The only link between these policies and the AS could be that the RS must specify which of the 50 clauses applies to a specific transaction to be authorized by the AS. In most cases, this metadata would not be "understood" by the AS but it would be part of the transaction logs. Occasionally, it could be linked by the RO to specific AS behavior as a kind of exception. For example, I might configure my AS to reject authorizations bearing the Facebook Policy Tag 7g without any particular standard or policy calculus.

From my perspective, the principal role of my AS is to introduce convenient _centalized_ transparency and notice into the data use practices of my service providers along with an opportunity to occasionally opt out of a transaction.

Adrian

On Wednesday, September 30, 2015, James Hazard wrote:

...

One of the Facebook documents and one of the Twitter documents are now in component form. On the Facebook doc, there are some names for section components, positing a taxonomy. These names (mostly verbs) are simply a guess, and non-exclusive (the same materials can be recombined using different names). But, IMHO, evocative. In any event, a starting point.

http://cmacc-uma.herokuapp.com/index.php?action=source&file=/Wx/com/facebook/developers/policy/Form/Doc_v01.md

Both docs live in this tree: http://cmacc-uma.herokuapp.com/index.php?action=list&file=/Wx/com/

A theory of such trees is at: http://new.commonaccord.org/index.php?action=list&file=/

On Tue, Sep 29, 2015 at 5:03 AM, Eve Maler wrote:

...

I started collecting a few of these here:

https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Examples-of-Term...

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

PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

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 PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/