Re: [WG-UMA] for those who need the link -

3 Sep 2015

      On Participation Agreements -

Participation Agreements are obviously peripheral to the direct mission 
of the legal group, but there are synergies in the communities and 
solutions.  So - in a really quick iteration - with some obvious places 
for improvement:

http://cmacc-uma.herokuapp.com/index.php?action=source&file=/ParticipationAgreement/Form/Ang_Consent.md

This sets up the consent and persons as objects.  Uses the "Principal" 
key word in identifying Acme, in line with Restatement of Agency.

The consent text could be further generalized, merging energies with 
other open source communities.

On 9/2/15 11:51 PM, Mark Lizar wrote:
...
Wow.
Yeah.. something like this would do !!
...
On 2 Sep 2015, at 15:16, James Hazard mailto:james.g.hazard@gmail.com> wrote:
On 9/2/15 5:27 PM, Mark Lizar wrote:
...
James,
This really good feed back and I think ties in very much with 
on-going work - I have been trying to tie down the overlaps in 
policy and their relationship to UMA as well.  Your two thoughts are 
inspiring.
More comments in line.
Mark,
Many thanks!  I do see the fit with the CISWG common consent.  The 
sequence of documents that you describe - Privacy Policy, ToU - is 
probably common, but even if it varied the parties could use standard 
record formats.  These would sometimes be followed by other events 
such as notifications, objections, complaints - like in the escrow 
example.
The discussion in Article 29 WP Opinion Paper 
http://idpc.gov.mt/dbfile.aspx/Opinion3_2013.pdf is great (I love 
the astonishing variety of the examples).  Perhaps the goals of 
transparency can be advanced with a charter that rephrased the 
obligations as text for privacy policies.  I believe this would be a 
great service for smaller companies who wish to comply but have 
limited resources - and a way for regulators to get on the same page.
There could be a list of permitted uses (establishing a taxonomy) in 
which each list item was associated with the text describing the use 
and a short title, etc.  It would be open-ended to allow for 
additional items. The elements of the list could be recombined for 
various privacy policies - and therefore be both human and 
machine-readable (in a soft but very effective sense) and provide the 
subject (Principal, etc.) with a chain of links back to the original 
element and surrounding commentary and discussion.
From that list and charter it would also be possible to establish 
multilingual equivalencies and other use cases - and maintain machine 
readability.
Modularity and recombination reduce the difficulties of 
standardization. This is the genius of open source software 
collaboration - forking and merging as incremental working consensus.
Jim
...
...
On 29 Aug 2015, at 12:44, James Hazard  
wrote:
Just now reviewing the discussion at 
https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles.... 
It repeatedly surprised me with it's broad and persuasive 
analytical position of the issues.
Two thoughts:
1.  We could work on a taxonomy of legal issues and provisions.  
The taxonomy could include ideas such as signature, authorization, 
revocation, ownership, disputes, etc.  We already have a lot to 
work with from the discussion, and can also work backwards from 
precedent documents.  A small way to start would be an outline for 
ToU or system rules.  We could focus on US health records, while 
keeping an eye on expanding it to non-US, non-health, non-English, 
etc. Statutory and other "primary" materials could be linked to.  
We could also link to lists of model and precedent documents.  
(Something similar was done by some UMKC students in connection 
with municipal data sharing agreements, sponteneously or at Dazza's 
suggestion.)
In the Consent & Information sharing Work Group we have been working 
on a common consent record format.   This provides an easy way to 
start for scenaros that involve explicit consent and personal 
information. Which I think covers all of UMA?  (if we assume that 
term User in UMA is = to a person) (is this correct Eve?)
It would seem the order of policy operations is first the privacy 
policy covering consent and attribute provision by the Principle, 
(which is governed by privacy policy)  then there are services Terms 
of Use policy form the  service provider.    The terms (if I am not 
mistaken) are subject to this privacy policy.  (to over simplify) 
 The privacy policy appears to represent the requirements to the 
service provider and the terms  appear to represent the requirements 
from the service provider.
A Principal interacts with an identity management system claiming an 
identity to a relying party in order to interact with services and 
access resources in a domain.  Terms are then presented to this 
identity.  In a consent receipt the attributes are provided after 
the purpose for those attributes (all found in existing policy) AND 
are used to on board - privacy and data protection. Which in this 
context would be provided at least in part by UMA.
...
2.  It might be simplifying and empowering to generalize the notion 
of "events" - to treat all events that might need to be legally 
proved as being effectuated by records in a common format.  For 
swimlanes, each step (lap in the pool?) should generate a text 
record that renders into a document and is shared among the 
directly concerned parties.  The record would render a 
document/webpage such as ToU or the NYPH patient consent, or as 
little as a mere selection or "yes" in the context of a form.  The 
format of the records would be such that they can be added to a 
log.  Each party would have (or have the right to) a log of the 
interaction.
The key in the CIS work is the requirement for a purpose specification:
Purpose Specification - [discussed deeply in this Article 29 WP 
Opinion Paper http://idpc.gov.mt/dbfile.aspx/Opinion3_2013.pdf 
] "The purpose of the collection must be clearly and specifically 
identified: it must be detailed enough to determine what kind of 
 processing is and is not included within the specified  purpose, 
and to allow  that compliance with the law can be assessed and data 
protection safeguards applied.
Purpose specification lies at the core of the legal framework 
established for the protection of personal data. In order to 
determine whether data processing complies with the law, and to 
establish what data protection safeguards should be applied, it is a 
necessary precondition to identify the specific purpose(s) for which 
the collection of personal data is required. Purpose specification 
thus sets limits on the purposes for which controllers may use the 
personal data collected, and also helps establish the necessary data 
protection safeguards.
Purpose specification requires an internal assessment carried out by 
the data controller and is a necessary condition for accountability. 
It is a key first step that a controller should follow to ensure 
compliance with applicable data protection law. The controller must 
identify what the purposes are, and must also document, and be able 
to demonstrate, that it has carried out this internal assessment.”
This is the native trust framework in consent and notice and I think 
legally where access controls can be onboarded by the individual.
...
Somewhere early in the interaction (in a ToU or the like, perhaps 
system-wide or jurisdiction-wide) there could be a stipulation of 
formal requirements. E.g., for an event to be legally cognizable it 
must: 1) be in the form of a record "signed" by the party to be 
charged,  2) each party must "have" a copy ("have" can mean 
immediately possession or have permanent access to), 3) legal 
provisions that are knowingly derived from publicly-available 
provisions must link to the original and be able to show the diff.  
(In the old days, each party received an original of signed 
agreements!)
This is understood in the Consent Receipt work as Purpose 
Specification and is the only common requirement across all of the 
jurisdictions and it requires a notice, but, information sharing 
also requires notice (from service provider to Principal).  This is 
where UMA and consent clearly interact in the authorisation flow.
...
The escrow demo and some of the work Adrian and I did show the 
notion of laps in swim lanes - 
(http://www.commonaccord.org/index.php?action=list&file=doc/escrow/). 
This can be extended to even small interactions such as radio 
buttons or yes/no dialog boxes.
For online transactions that involve any /sensitive/ personal 
information - like Health Care, or finances, explicit, specific and 
legitimate consent is required as explained in that Article 29 
paper.  Every jurisdiction and vertical have these types of specific 
notice and consent requirements and these end up being radial or 
check boxes developed as a result of policy.
It may prudent to start with the Health Care use case, create a 
consent receipt for it, then use the data in the consent receipt and 
compare this to the authorisation in UMA to understand what this 
logging format will actually consist of.  (I wish I had this type of 
time)   I would pick this as a starting point to answer questions 
like:  How does legal policy requirements  translate to UMA and vice 
versa?
In the CIS we are currently working on formalising the  purpose 
specification aspects so that these can be usable.  It is my hope 
that this legal sub group will inform this formalisation so the 
consent record format can work almost natively with UMA.  We still 
have lots of work to do in order to get this far though.
...
I have not worked much on logs.  In blockchain implementations, the 
records and logs are (from the perspective of CommonAccord) an 
application-side implementation issue.  The log is necessarily 
shared on the blockchain and the challenge is to avoid 
over-circulation of the information (e.g., using sidechains).  In 
non-blockchain, a log could be kept by having each record added to 
a log as a single JSON-formatted line of text, with some metadata 
such as a GUID, time and author.  The JSON aspect ties in with a 
discussion on a GitHub issue that I did with Dazza on design of a 
more modular and generalizable implementation of CommonAccord 
rendering.
There is some excellent work going on in ISO 29100 which we are 
feeding into as well.  This work provides a lot more information, 
part of which specifies adding to the consent record and should be 
represented in the v.0.8.  At the moment we are on the vanguard of 
developing a common purpose specification framework for the consent 
receipt and I am looking to UMA requirements and implementation to 
help drive this work.
In fact, the concept of a consent receipt was originally developed 
with UMA or (cop monkey) as a conceptual anchor and I suspect this 
method of approach (of consent specification to UMA resource access 
policy) will greatly facilitate and open the way for  terms of use 
policy interaction.   Their are a few Open Notice type of projects 
out there that have driven work in this space like.  Common Terms, 
from Par Lanero, TOS:DR, both services that could used a common 
record format to attach a framework to.
...
Expecting to be better connected starting on September 2.
If you have a chance,  check out the Article 29 WP paper. 
http://idpc.gov.mt/dbfile.aspx/Opinion3_2013.pdf Eve had previously 
asked me to post this during a call two weeks ago  (apologies for 
the delay in posting)
Some notable quotes:
"Consent is a pre-requisite for data quality requirements”.
and
"When applying data protection law, it must first be ensured that 
the purpose is specific, explicit and legitimate. This is a 
prerequisite for other data quality requirements, including
adequacy, relevance and proportionality (Article 6(1)(c)), accuracy 
and completeness (Article6(1)(d)) and requirements regarding the 
duration of retention (Article 6(1)(e)). In cases where different 
purposes exist from the beginning and different kinds of data are 
collected and processed simultaneously for these different purposes, 
the data quality requirements must be complied with separately for 
each purpose. If personal data are further processed for a different 
purpose the new purpose/s must be specified (Article 6(1)(b)), and 
it must be ensured that all data quality requirements (Articles 
6(1)(a) to
(e)) are also satisfied for the new purposes. “
and
*“ User control*
User control is only possible when the purpose of data processing is 
sufficiently clear and predictable. If data subjects fully 
understand the purposes of the processing, they can exercise
their rights in the most effective way.  For instance, they can 
/object to the processing /or request the /correction or 
deletion/ of their data.  As will be developed below, this does not 
mean that the presented purpose should always be trusted as the 
actual and effective one, as there may be a discrepancy between what 
is claimed and what is pursued in practice by the data controller. 
 Ultimately, compliance with other data protection requirements, 
such as the necessity and relevance of data, will always need to be 
measured against the actual purpose”
Kind Regards
Mark
PS> Eve:
...
On 8/28/15 6:35 PM, Dazza Greenwood wrote:
...
The legal subgroup is reviewing use cases now here:
https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles...
Also, we are walking through some healthcare wrinkles that Adrian 
contributed, here: 
https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLr...
Thanks,
 - Dazza
_ _ _ _ _ _ _ _ _ _ _ _ _ _
   |   Dazza Greenwood, JD
   | CIVICS.com http://civics.com/, Founder & Principal
   |   MIT Media Lab, Visiting Scientist
   |     Vmail: 617.500.3644
   |     Email: dazza@CIVICS.com
   |     Biz: http://CIVICS.com http://civics.com/
   |     MIT: https://law.MIT.edu https://law.mit.edu/
   |     Me: DazzaGreenwood.com http://dazzagreenwood.com/
   |     Twitter: @DazzaGreenwood
   |     Google+: google.com/+DazzaGreenwood 
http://google.com/+DazzaGreenwood
   |     LinkedIn: linkedin.com/in/DazzaGreenwood 
http://linkedin.com/in/DazzaGreenwood
   |     GitHub: github.com/DazzaGreenwood/Interface 
http://github.com/DazzaGreenwood/Interface
   |     Postal: P.O. Box 425845 Cambridge, MA  02142
   | _ _ _ _ _ _ _ _ _ _ _ _ _ _
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
-- 
@commonaccord
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
-- 
@commonaccord
-- 
@commonaccord