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.

On 29 Aug 2015, at 12:44, James Hazard <james.g.hazard@gmail.com> wrote:

Just now reviewing the discussion at https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles... <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations>. 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/ <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 <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... <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations>

Also, we are walking through some healthcare wrinkles that Adrian contributed, here: https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLr... <https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLrRh8/edit>

Thanks, - Dazza

_ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza@CIVICS.com <mailto:dazza@CIVICS.com> | Biz: http://CIVICS.com <http://civics.com/> | MIT: https://law.MIT.edu <https://law.mit.edu/> | Me: 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 <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Wow. Yeah.. something like this would do !!

On 2 Sep 2015, at 15:16, James Hazard <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 < <mailto:james.g.hazard@gmail.com>james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote:

Just now reviewing the discussion at https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles... <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations>. 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/>http://www.commonaccord.org/index.php?action=list&file=doc/escrow/ <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 <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... <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations>

Also, we are walking through some healthcare wrinkles that Adrian contributed, here: <https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLrRh8/edit>https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLrRh8/edit <https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLrRh8/edit>

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 <mailto: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 <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <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 <http://kantarainitiative.org/mailman/listinfo/wg-uma>

-- @commonaccord

Jim, My mapping of UMA with the Resatememt of Agency has the patient/subject as Principal and the service provider, Acme, as the Third Party. The Agent, I think, would be the proxy that signs the Participation Agreement On the Principal's behalf and the place where Acme sends the Consent Receipt. Adrian On Thursday, September 3, 2015, James Hazard <james.g.hazard@gmail.com> wrote:

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 <james.g.hazard@gmail.com <javascript:_e(%7B%7D,'cvml','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 < <javascript:_e(%7B%7D,'cvml','james.g.hazard@gmail.com');> james.g.hazard@gmail.com <javascript:_e(%7B%7D,'cvml','james.g.hazard@gmail.com');>> wrote:

Just now reviewing the discussion at <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations> 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/> 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> 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-tsUGoXEFDpEwxNLrRh8/edit> 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: <javascript:_e(%7B%7D,'cvml','dazza@CIVICS.com');> dazza@CIVICS.com <javascript:_e(%7B%7D,'cvml','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 | LinkedIn: linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _

_______________________________________________ WG-UMA mailing listWG-UMA@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','WG-UMA@kantarainitiative.org');>http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <javascript:_e(%7B%7D,'cvml','WG-UMA@kantarainitiative.org');> http://kantarainitiative.org/mailman/listinfo/wg-uma

-- @commonaccord

-- @commonaccord

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

Struggling to keep up with the traffic on the list. (This makes me happy. :-) Excerpting heavily below to add some tidbits:

On 2 Sep 2015, at 8:27 AM, Mark Lizar <mark@smartspecies.com> wrote:

...

On 29 Aug 2015, at 12:44, James Hazard <james.g.hazard@gmail.com <mailto:james.g.hazard@gmail.com>> wrote:

Just now reviewing the discussion at https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles... <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations>. 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?)

The “user” in User-Managed Access was originally intended to be Alice, our resource owner. We “solved for” the hard use cases where an individual was a resource owner, and then subsequently realized that nothing was stopping the resource owner from being an organization or other non-person entity. Thus, the RO role is not technically constrained. (The requesting party role is similarly unconstrained.) This matters for things like how each of them might, say, authenticate to a system, or whether it’s possible to redirect the RqP to the authorization server or not (it only works if they’re a human end-user). Of course, many laws treat them differently as well, so it’s good to take the distinction into account and be specific.

...

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.

Laps in the pool, nice… Effectively, this is what we tried to do prior to developing the Binding Obligations spec. I’ve gone nuts trying to find one of the old diagrams and failed, but we basically analyzed every single pairwise relationship and every single interaction between them, then tried to identify which interactions really “meant” something and would be worth capturing a mutual log out of because somebody’s responsibilities had changed. Issue 63, Audit logs to support legal enforceability <https://github.com/KantaraInitiative/wg-uma/issues/63>, is about this as well. I’ve been thinking of consent receipts as a special case of transaction receipts marking such occasions — sort of audit log entries that are optimized to help human beings know/prove what happened or what they did, by having machine-readable elements. Seems we’re reaching convergence on this, roughly?

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.

In the past, Dazza and I and others have batted around some ideas about where we could put purpose limitations in an UMA flow. One model is to embed metadata in scope descriptions (which becomes a kind of API-wrap). Another is to require the requesting party to provide a claim confirming your request for them to adhere to some purpose limitation, or to select values for some required claim type that indicate their willingness to adhere to the purposes corresponding to those values. There are no doubt others.

...

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.

To date, we’ve stayed away from normative specifications of technical log requirements because each industry seems to have unique requirements. E.g., HL7 has its own. But we’ve gotten close a couple of times! Eve Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com