We have agreed that the legal framework is designed to protect privacy rights (see the mission statement: https://kantarainitiative.org/ ), and out of all the scenarios we have identified so far, any ones having an organization in the resource owner role are not where we’re spending our energy right now. Basically we’re doing all the individual-to-* scenarios. Where this includes other individuals, we are also looking out for their rights.confluence/display/uma/UMA+ Legal It could be that the whole thing will easily be extensible in the other direction, but we don’t want to presume.(We can probably use text approximately like this but formalized in the doc.)Eve Maler (sent from my iPad) | cell +1 425 345 6756Apologies for mostly lurking on our groups but UMA is still the center of my world.In the notes below, what is meant by “We could note that org-to-whoever sharing is out of scope for this exercise (framework)”?AdrianOn Fri, Nov 10, 2017 at 8:51 PM Eve Maler <eve@xmlgrrl.com> wrote:https://kantarainitiative.org/______________________________confluence/display/uma/UMA+ legal+subgroup+notes# UMAlegalsubgroupnotes-2017-11- 10 2017-11-10
Attending: Eve, Jeff, Devon, Theresa, Mark, Kathleen, Tim, Ann, John
Doc homework:
- A very early section (the first?) should present the "pain point" by introducing several broad scenarios, including an Alice-to-Alice, Alice-to-Bob, and Alice-to-org, drawing from deliverable #1. It could introduce the language of "resource owner" and "requesting party". We could note that org-to-whoever sharing is out of scope for this exercise (framework). We could have a very high-level version of the x-and-y-axis scenario diagram that just talks about these two roles. and then the version with the three high-level scenarios.
- In NewSec, we want to make the strongest case we can for our chosen legal devices, and ultimately for our biggest target type of toolkit (templates of some sort).
- Later, we can get into the sub-scenarios we have collected, e.g., Alice as a guardian of a data subject too young to consent etc.
The "collaborative diagrams" in the GSlides need more differentiation and "iconification".
"Model clauses" specifically means they need regulatory approval, so how about "template clauses" or even "clause templates" or something? Templates will do for now.
Let's get more specific about pain points.
"Through a combination of strengthening data protection regulations, justified consumer cynicism and savviness about poor security and AdTech/MarTech ecosystems, and good rationales for data sharing, particularly in the cases of healthcare and the Internet of Things, we're seeing people start to be given just a little more transparency into and control of their personal data. Organizations have never had more incentives to make changes and reduce friction..."
The healthcare construct of a "consent directive" can be directly and favorably compared to ToS opt-in (or, for that matter, opt-out – soon to be made effectively illegal by GDPR) as a mechanism for inviting individuals to express their data sharing preferences in ways that are not influenced by outside actors. UMA enables this construct to be digitized in a standard and repeatable way. This framework enables it to be
AIs:
- Eve: Create two new scenario diagrams ready to put into the GDoc:
- Very high-level diagram introducing "RO" and "RqP" language
- Fixed three-scenarios diagram
- Tim: Flesh out the licensing framework itself
- Possibly this includes the rationale as started in the comment on NewSec
Be sure to see all the new comments in the doc.
_________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
https://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.