Brief response from tiny keyboard. Privacy Policies are/should be relatively static documents that provide guidance to an organization. What we are talking about vis-a-vis UMA specs seem more related to a series of discrete transactions and/or relationships that need to be captured in a relevant set of commitments - which could be different depending on the stakeholders in any given data flow. 

Sent from Outlook Mobile. Yes, it works with gmail.




On Mon, Mar 14, 2016 at 9:17 AM -0700, "James Hazard" <james.g.hazard@gmail.com> wrote:

I understand the point.  We could do that, and alternatives at the same time.  (Cheap branching.)  I think we end up in the same place - social knowledge and network benefits converge on some solutions that are more balanced than the current model.

"Privacy Policy" has the virtue of familiarity - companies at least know the role of the document.  There seems to be a competitive argument for having the wolf continue to appear as a sheep even as its more carnal impulses are tamed.

I would prefer Data Use "Policy" over "Warranty".


Privacy_Policy=Data Use Policy

http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/03-Policies/03-Automatted-Privacy_v0.md
 

On Mon, Mar 14, 2016 at 4:41 PM, John Wunderlich <john@wunderlich.ca> wrote:
Folks;

It seems to me that the term “Privacy Policy” is both much abused and much misunderstood (50% of surveyed users thought that the purpose of privacy policies is to protect their privacy - which is false). Rather than redefine or refine a term that is out in the wild and hard to pin down (i.e. let’s not rathole on what a privacy policy is or should be), can we perhaps come up with a term specific for our lexicon - “Data Use Warranty” comes to mind. I’ll take advice from the lawyers in the group but might not the term “warranty” be closer to what we are trying to accomplish in terms of what the various operators are committing to by participating in an UMA relationship?

http://www.forbes.com/sites/andygreenberg/2012/01/25/the-worlds-worst-privacy-policy/ 
​

JW



Sincerely,
John Wunderlich
@PrivacyCDN

Call: +1 (647) 669-4749
eMail: john@wunderlich.ca

On 13 March 2016 at 13:45, James Hazard <james.g.hazard@gmail.com> wrote:
This makes sense to me.  It would be useful to start with a document that we have some comfort with.  Would that be the Automattic privacy policy?




On Sun, Mar 13, 2016 at 5:26 PM, Adrian Gropper <agropper@healthurl.com> wrote:
Seems like we're converging on a possible structure for our Legal deliverables. I can't draw out the structure, but is seems to have some fundamental properties:
  • The UMA base cases are a small number of two-party agreements where RS==RSO, AS==ASO, and C==RqP
  • Two party agreements have both short record that highlight exceptions from a stable baseline and full text depictions.
  • Two party agreements are rendered and executed in specified host contexts (RS, AS, C).
  • Additional or secondary agreements extend the base cases when the RS, AS, or C serve multiple parties.
  • Does UMA require agreements with more than two parties?
 Adrian

On Sun, Mar 13, 2016 at 6:13 AM, James Hazard <james.g.hazard@gmail.com> wrote:
Totally agree on point two - make a list of use-cases and we can fill in the agreements, connecting the use case to the Automattic policy (or another model), to comments and to machine-readable annotations.

On the first point - you get both a short record and full text, and unless I'm missing something, you need both.  

a) a short form receipt - date, signature, any specially-agreed terms and links to i) the parties's identities (adding to the graph) and ii) to; 

b) a complete statement - which can be expressed as "an agreement" between the parties (click on "Document" and you get a full-text, signed agreement) or could be expresses as a Master Agreement/ToU - (the short form receipt being a document "under" the MSA/ToU).  

Technically, both of these can be done the same way, its just a matter of how you organize the text.  But the complete statement (b)) will itself be made as a list of changes on a base, etc.  Turtles.




On Sun, Mar 13, 2016 at 12:07 AM, Adrian Gropper <agropper@healthurl.com> wrote:
IANAL but I don't see where we need a full-text agreement vs. a simple form with appropriate references and exceptions.

To get things going, can we start with: How many different full-text agreements will there be where one of the parties is the RSO?

We can deal with agreements that do not include the RSO as a party later.

Adrian

On Sat, Mar 12, 2016 at 3:14 PM, James Hazard <james.g.hazard@gmail.com> wrote:
You could do that.

A group could establish a number of variations on policies based around a core.  Each variation would be a list of changes on the core, and each would have a URL that listed the differences and rendered into a full-text agreement. The supplier would list such of the variations as they felt comfortable with.  The user could choose.  Or the process of matching could be automated.  The critical difference between a CommonAccord approach and similar approaches is that you don't have to have full agreement to get benefit.  It is not 4 varieties of Creative Commons, but 4 plus variations, and each branch renders into a full document.  "Cheap branching." 

The "standard" text could also be tied into into regulations or a quasi-legislative process.
(This is not a real policy, it just shows the chain of text approach from regulation to charter to policy.)







On Sat, Mar 12, 2016 at 8:18 PM, Adrian Gropper <agropper@healthurl.com> wrote:
+1 James

The baseline UMA model clauses should be for the case where RS==RSO, AS==ASO, and C==RqP. In each of these three cases, by definition of ==, there is no privacy notice for the RS, AS or C respectively. As you suggest, this would be the case where the RS is a door lock solenoid, the AS is a FreedomBox, and the C is an email client. In this baseline case, the only privacy notices and agreements would be: RSO-ASO, RqP-ASO, and RqP-RSO.

What I imagine is that the ACME RSO-RO sign-up agreement replaces the familiar:
  • [  ] I accept the ACME Privacy Policy.

with

  • [  ] I accept the ACME Automattics_3 Privacy Policy.

or

or even better, 
  • [  ] I accept the ACME Automatics_2 Privacy Policy via my authorization server at http://agropper.xyz/
In the last example, the RSO-RO agreement would no longer be a "notice" but actually be an agreement with technical agency for both the RSO and RO (as peers).

In the last example, the ACME RSO privacy notice and any exceptions would be presented to the RO in the context of their AS and make the registration process truly consumer-centered.

Adrian

On Sat, Mar 12, 2016 at 1:35 PM, James Hazard <james.g.hazard@gmail.com> wrote:
On the question of user/patient/owner/peer control, my sense is that peer control naturally flows from a real P2P system.  The mission of CommonAccord - and a "Center for Collaborative Law" - is strictly limited to integrity of the text and the discussion, not to any particular outcome.  But ....

In a P2P system, even large organizations and groupings are peers, and they will insist on control of their own identities.  It is costless to extend that solution to smaller organizations and individuals.  Coming from the other direction, the IoT requires a kind of sovereignty for each gadget.  So each thing, including even "Individuals", will at least have the option to control their own client.  As we now do with our email clients.

 
    

On Sat, Mar 12, 2016 at 7:04 PM, Adrian Gropper <agropper@healthurl.com> wrote:
I'm much more interested in how to make best use of CommonAccord with UMA than trying to boil the ocean of passive-aggressive privacy practices. We can use CommonAccord to pave the cow path of 20-page privacy notices and then try to link that to 200 model clauses in tangle of UMA relationships. Or, we can structure the use of CommonAccord at two separate levels: one that standardizes the baseline and is shared among all of the services and actors in a particular domain, and another that captures the deviations from that standard in the case of a specific RSO and a specific ASO.

The Automattics privacy policy is an example of a good candidate for the social media RSO policy standard. It should be relatively stable the way OSI or CC licenses are stable from year to year unless some really new tech or business model comes along. CommonAccord is of relatively limited value in managing a standard policy or license that's generic within the domain, stable, and not meant to be negotiated.

CommonAccord will then be incredibly valuable if it's applied (only) _to the exceptions_ from the standard and negotiated with the parties to an UMA relationship. That will result in much shorter output documents, sometimes with only a handful of lines. The UMA relationships would be much easier for all to understand in that case as well.

I love UMA because I take the user-managed access as an enabler of user-centered technology. Not everyone in our group sees user-mananged as user-centered and I understand that UMA needs to serve both. In the user-centered case, the UMA authorization server will be called upon to serve RSO domains as different as social media is from healthcare and from IoT. (Some clients can also be expected to serve people across domains). By applying CommonAccord to the exceptional aspects of the privacy notices of RSOs we have a prayer of actually making UMA agreements person-centric.

Adrian

On Sat, Mar 12, 2016 at 12:53 PM, James Hazard <james.g.hazard@gmail.com> wrote:
I think that you end up with at least as good a solution as Adrian wants, and the road incorporates work such as TosBack2.  The point is to lay efforts end-to-end and to enable sources of "social" knowledge.  That can happen by treating legal text like source code.


IF LAWYERS ARE AS CODERS - LET US GET GOOD AT IT -  (tip of hat to Whole Earth Catalog)

The open source software community has shown how to iterate to first-class results on very complex matters expressed as text (software source code), without top-down.  The conditions are:

1.  Frequent, widespread, immediate need for _a_ text solution, however imperfect.  In software that might be to print a document, serve a webpage, validate a user.  In law it might be an NDA, Master Services Agreement or privacy policy.  The immediate need drives the rest.

2.  Modularity.  So that we can separate idiosyncratic or confidential from general and repeating.  Mix, match, improve. 

3.  A platform for collaboration.  Um ... GitHub.

Privacy policies have similarities as well as differences.  A good one would be helpful to others with similar needs.  If there is a way to mix and match that maintains traceability, then the community can leverage efforts of Automattic, and everyone else.  A simple approach is to break up the documents at their section and subsection breaks and parameterize the variables.  You can chop finer as needed.  

Here are a few more privacy policies available for mixing: http://privacy.commonaccord.org/index.php?action=list&file=/Com/

The privacy conversation between EU and US could be leveraged to play a critical role in driving P2P (see especially the pumpkin-colored part near the end):




On Sat, Mar 12, 2016 at 6:19 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
You've missed my point.

The analysis and ontology work that went/is going into TosBack2 is the piece you might want to explore. You are looking for a simplified representation of policy - but until you examine the structure and conceptual meanings of the policies that will be simplified, there's a risk of missing important pieces.

Just a suggestion, rather than re-inventing and creating new uses for words...

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, Mar 12, 2016 at 9:12 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Yes. TOS Back has the same goal but is the exact opposite of what I'm proposing. It presumes that there's some value to the consumer for having 20-page privacy policies and terms of use that are heavily customized for every service we visit. We might call this the passive-aggressive approach to authoring and managing privacy notices. Just because we can create 20 page custom legal documents for an apartment lease or a privacy notice doesn't mean there's actual value to the consumer in doing so. A privacy notice is not the same as a piece of source code and should not need a Diff function run by experts to be understood. Privacy notices can be standardized.

We standardize software licenses and apartment leases for a reason. We do it to help typical people understand any unusual exceptions, good or bad, from what might be expected in the particular domain. The problem is that standards organizations are funded by commercial interests and making privacy notices easier to understand and to enforce is not likely a priority yet. As ad-blockers and GDPR begin to add real costs and benefits to privacy practices, we can expect to see a shift toward standardization.

Adrian



On Sat, Mar 12, 2016 at 11:44 AM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
Not completely on topic, but Adrian: have you seen the ToSBack2 project from ISOC?


I have not plunged into the abyss of reading the documentation... but I suspect that they have created a functional ontology for privacy policies that enables the analysis engine to do cross-version comparison. That might save some thinking work about how to slice and dice then represent the policies...

just a thought.

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, Mar 12, 2016 at 4:42 AM, James Hazard <james.g.hazard@gmail.com> wrote:

On Fri, Mar 11, 2016 at 10:29 PM, Adrian Gropper <agropper@healthurl.com> wrote:
Thanks, for sharing this. From my strictly consumer perspective, here's what I would do with this:
  1. Start a Standard Privacy Notice workgroup in Kantara with a narrow charter to classify and label privacy notices.
  2. Make the Automattic Policy the first label and post it the way we would a CC or OSI license.
  3. Publish a DRY Privacy Notice Best Practice that would incorporate a labeled privacy notice BY REFERENCE and list only the exceptions, if any to the referenced policy.
  4. Add CommonAccord to this as an option for describing only the exceptions.
  5. Suggest standardized formatting for the exceptions right down to the fonts and colors.

My guess is that the world can get by with only 5 or so of these baseline privacy notice labels to serve, for example:

  • blogs, (Automattic)
  • merchants, (Vendor)
  • things, (Robot)
  • medical services, (HIPAA)
  • directories (Dating)

In addition, I would classify each privacy notice into one of three classes depending on the kind of API they provide:

Class 1: Service will not see your data. You are in sole control of the API.

Class 2: Service will see your data but the API you control has all of the data available in reral-time.

Class 3: Service will see your data but there's limited or no API access.

I've described these three classes in http://thehealthcareblog.com/blog/2016/02/22/apple-and-the-3-kinds-of-privacy-policies/

The result would be that Kantara privacy notices would look like: Automattic_2 or HIPAA_3 and people would mostly pay attention only to the exceptions.

Adrian


On Fri, Mar 11, 2016 at 12:31 PM, Eve Maler <eve@xmlgrrl.com> wrote:
On today's call, I mentioned a cool privacy policy I ran across when I downloaded this app:


The app costs $4.99, and I carefully looked at the policy and decided I was very willing to pay money -- and they were making the tradeoff very worthwhile. They based the policy closely on this (both are CC-licensed -- hooray for DRY content!):


BTW, the app is awesome too.

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




--
@commonaccord

_______________________________________________
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/




--
@commonaccord



--

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/



--
@commonaccord



--

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/



--
@commonaccord



--

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/



--
@commonaccord



--

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/



--
@commonaccord

_______________________________________________
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.



--
@commonaccord


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.