- WG-UMA - mailman.kantarainitiative.org

Reminder: UMA legal subgroup telecon 2015-08-21
by Eve Maler 25 Aug '15

25 Aug '15

Fri Aug 21 8-9am PT Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# Screen sharing: http://join.me/findthomas <http://join.me/findthomas> - NOTE: IGNORE the join.me <http://join.me/> dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar <http://kantarainitiative.org/confluence/display/uma/Calendar> Analyze new (positive and negative) use cases sent to the list Is this list complete enough to be going on with, for our purposes? Do we need to capture use cases for different “topologies" (deployment ecosystems) too? What would “structuring the transaction” look like in terms of accomplishing our mission? How would consent receipts/logging/auditing come into play? (I apologize for getting this agenda out so late!) Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

3 9

Rethinking our resolution to #161/#162 (protocol assumes one resource per URL/RO)
by Eve Maler 23 Aug '15

23 Aug '15

When we discussed this on the last call, we gained consensus around wording as follows (emphasis added — hopefully the formatting will make it through): "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource without any context to guide it. In practice, this likely means that the URI reference used by the client needs to be unique per resource set.” In the previous week’s discussion, I’d had a high-level suggestion for a strategy for providing RO context, which we discussed briefly and concluded didn’t satisfy the goal to let existing APIs stay as they are, but thinking about it again, I’m not sure why that is. Let me run through it in detail. If the RS has an API that is completely generic per RO, such as a singular endpoint that normally depends entirely on an OAuth token to convey the user context, it would similarly register that singular resource set over and over for each of its many users (each using a different PAT) at an AS, getting a unique resource set ID for each in turn. It does indeed have to be prepared to associate some attribute with a resource set that can later be matched up with the PAT, and then what remains is for a client to provide that attribute somehow when attempting access with no token. Depending on the nature of the API, the context could be in a query parameter, or something in the request body. So “without any context to guide it” in our wording isn’t strictly true. The approach I mentioned on the call was what appeared in our wireframes as an “authorization code” that the AS would send in an email notification to the RqP, which the client would use in attempting access. That probably wasn’t quite the right way of envisioning the UX, but I think Justin was saying that this requires propagating changed URI structure all the way through. I don’t believe this is needed. Here are several ways to complete the PAT-to-client-context chain for a resource set given our same example, using the “uri” location property of the resource set description, which is optional and the only part of a resource set description that isn’t entirely abstract: If the RS registered the endpoint with some kind of query parameter on it identifying the RO, discoverability would be possible, at (what I believe is) the small cost of inventing a “new URL” just for the purpose of user discoverability but not real URI namespace management. Thinking about Twitter’s API, it would be possible to look up “Alice in Twitter”, “Bob in Twitter”, etc. in the directory and attempt access to their protected Twitter endpoints without inventing new API structure. If the RS and AS had the opportunity to extend the resource set description JSON structure for extra discoverability features, the RS could add a property for RO identity, enabling an out-of-band means for the requesting side to discover and convey RO identity in, say, a request body. If the RS registered only the generic endpoint, indeed discoverability wouldn’t be possible without a totally out-of-band RO hint provided somehow. If this thinking is correct, I think it would be a good idea to revise our wording because we were trying to signal something about the nature of the RS API, but backed off of it and — while making a potentially true statement about the client API call — overstated the case by getting into implementation detail (“the URI reference used by the client"). I suggest making the following revision: "Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource set identifier associated with that resource. If the interface presented by the resource server is not resource owner-specific, the client needs to supply sufficient additional context as part of the resource request. See the [UMA-Impl] for advice on ways to accomplish this.” …and then, obviously, adding something like the analysis above to the UIG. (Note that I call it “interface” and not “API” because we do that elsewhere in the spec; we don’t presume it has an API in the classic sense.) Thoughts? Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 5

groundwork for non-vertical-specific legal use cases
by Dazza Greenwood 22 Aug '15

22 Aug '15

Some groundwork on developing legal use cases for discussion next week is forwarded below. More general background on the law of agency is available at: https://en.wikipedia.org/wiki/Law_of_agency ---------- Forwarded message ---------- From: Dazza Greenwood <dazza(a)civics.com> Date: Fri, Aug 21, 2015 at 2:59 PM Subject: Re: [WG-UMA] Reminder: UMA legal subgroup telecon 2015-08-21 To: Eve Maler <eve(a)xmlgrrl.com> Cc: Mark Lizar <mark(a)smartspecies.com>, Adrian Gropper <agropper(a)gmail.com> Following up: For the next meeting, it sounds like the question is: What 2 or 3 use cases would "flesh out the AS possibilities"? The essence of two distinct alternative possibilities we discussed are: 1) Its an AS world and Alice just lives in it; and 2) The AS works in Alice's Restaurant. Eve, as always, you posed a really good question and I'd be happy to work on it for input to the next meeting. My own instinct is usually to go into the weeds of fact specific contexts like in HIPAA or the EU privacy directive. But upon reflection I like your proposed next step more and more because it logically is the first brick of an otherwise uncertain foundation. Here is my thinking: Currently, most of the legal context and basis for establishing rights and obligations of parties using UMA will source from the economic sectors and verticals in which UMA is deployed and used. This however is complex and confusing to analyze. The focus for next week is therefor to develop use cases that are not vertical-specific to any particular vertical. This also means keeping identity-federation-agnostic. This is a narrow scope focused on identifying, describe and defining the "base-case" legal roles and rules between Alice and the AS. The fundamental assumption in Scenario A is that the AS "works for" Alice in the sense that it "serves the interests of" or "is answerable to" or "directed by" or "the legal Agent of" etc Alice in some meaningful way. Examples of these relationships between individuals and organizations include investment banks who transact money or other assets of an individual and law firms who advocate for an individual. Identifying the legal dimension of the use cases from the perspective of generic "agency law" would give us traction to make good progress on the task for next week. It is possible to apply the rules of agency law without reference to other more specific legal relationships arising from roles associated with any particular economic sector or industry vertical context. Applying the rules of agency law is one way to credibly address the question of who will prevail in a dispute between the parties over protected resources. That means it provides a basis for concluding what bundles of rights or responsibilities any given use case actor has with respect to the other actors and to the protected resources at stake with UMA use cases. For a sound legal analysis it is important to have a sense of the nature of the thing at stake. If is a family member we have one analysis (maybe we can limit their TV watching but not take their TV) and if it is a city we have another (maybe we can out it into receivership but not under occupation). The most relevant legal aspect of OAuth 2 (hence UMA) protected resources is that they are property. These resources are basic boring normal property. They happen to be intangible property and that has been normal and boring for decades. No big deal. The nature of basic property is not specific to the idea of "intellectual property". That is another context that may or may not be important or even apply to any given intangible property, depending on the context. What definitely applies and provides a direct, simple and complete cross-walk to regular old vanilla agency law and heaps of other well understood and widely agreed legal fact patterns is the fact that these resources are also property. There exists a long tradition of roles and expectations about property rights and all that can usefully be vectored directly into the equation for Alice. It may be helpful to connect the dots and make a clear surface area for application of things like business models, legal terms and technical protocols. Among other things, data and other protected resources like services or rights to service levels etc are also property and people have "property rights" to buy, sell and otherwise slice and dice property rights. UMA legal use cases that focus on the specific rights or obligations linked to protected resources are tractable and totally avoid the needless debates about what "ownership" does or should it could mean if only everybody would agree to that definition. The question of ownership has been asked in many a personal data and electronic transactions forum and it is very definitely the case that everybody does not agree on a definition of ownership. And yet, it is frequently possible to find agreement on named rights and obligations with respect to data and other property. The concept of ownership suggested it is the sum total of all rights to property. One could say that "exclusive control, possession and enjoyment" of property is full ownership. Yet, much of the value and fun of having data and other stuff comes from sharing it. Most people would not have a home if the value was not shared with whomever hold their mortgage. Who owns the home when the mortgage is worth 90% or even 110% of the economic value of the property? The deed would says title owner is Alice and yet the word ownership is not really very important to the practical questions of who can do what. The basic roles are Principal (which is a reasonable fit with with UMA's happy Alice and 29100 Principal as well), and Agent and Third Party. It is as good a starting place as any I can think of and better than most. The authoritative source of agency law is the "Restatement" and it is both a source of voluminous case law and also boasts a lot of law school and other pre-argued "fact patterns" with broadly agreed legal "answers" and reasonably expected dispute outcomes. The presence of a lot of well worn fact patterns based on generations of case law and codified/formalized rules (ie the "Restatement") is very valuable for the purposes of this workgroup. The value of such fact patterns is they are carefully designed in a way that can be cross-walked to technical use cases pretty easily, providing a source of existing agreed legal scenarios with named roles and expected legal results to get us started. Coming up with that stuff from a blank slate and getting broad understanding and agreement on the expected legal results can be a daunting long term task and therefore makes it less likely this legal group could achieve its adoption oriented mission. As a side-note, part of what makes the UMA flavored Alice to Bob flows interesting is precisely that they shed light on the nature of roles individuals have in relationship to "service" providers. There are many layers of connotation around the legal concept of a "service provider" and decades of law school text books and bar exam fact patterns that routinely position such parties as agents providing a service for or on behalf of principals. This gives tools for lawyers to deliberately structure transactions by defining defining roles and corresponding legal rules to create predictable and beneficial legal outcomes for their clients. By contrast, typically in the modern mass-market networked economy it is the individual who works for and is the legal "agent" of one or more organizations which are the legal "principal" in that context. These are legal terms that apply to the "roles" of the parties and from which "relationships" can be revealed. Employment relationships, as an example, carry some predictable sets of rights and obligations and also vary to some degree depending on factors like the applicable jurisdiction(s), and other relationships the parties may also have with one another or with others (like when somebody is your patient but also your boss or your student but also your auditor, etc). In doing an AS relationship analysis that "non-vertical-specific" we have an opportunity to start with a very clean slate and just ask the level-setting question: what is the basic legal relationship and which roles in the relationship is played by each "party" (aka actor or entity or person) identified in the use case? This is a great question to level set for the call next week and provides a sound foundation upon which to clearly layer vertical-specific relationships and other important sources of context. It is possible to identify, clarify and simplify the context of use cases by just naming the legal roles/relationships of parties conducting transactions or other interactions. Once the legal dimension of context can be refined down to a few defined roles and interactions it is a lot easier to speculate on and have an opportunity to successfully deliberately structure the relationships and transactions to achieve more predictable intended legal results. Layering on "vertical-specific" financial services, educational, clinical care, municipal, commercial, law enforcement, workplace, etc contexts will provide a well of known and named sets of legal relationships corresponding to definite and repeating roles which can therefor be linked to each identified party in any use case. Typically a technical use case provides to little information to assign vertical (or other) specific legal roles to a given party with high confidence. This is signaled when a lawyer says "it depends..." when asked what legal roles applies. That goes double for the evrn more ambiguous question "who 'owns' this or that data or other property" in a use case. The good news is that by at least by answering Eve's question about non-vertical-specific and then some vertical-specific use cases and developing some consistent documentation of roles and other terms we will have built a tractable legal fact pattern. With that traction we can make progress to resolve the key sources of ambiguity needed for lawyers to make conclusions like "in use case xyz, Alice is the Principal, the AS is the Agent of Alice" and "in use case abc the AS is a "covered entity" under HIPAA and has a legal obligation to share Alice's resource with Bob upon Alice's signed consent and request to share". This is good and such traction is one way to achieve the mission statement of this legal subgroups. When a lawyer says "it depends" the opportunity is to elicit the factors upon which a legal conclusion about the situation depends and therefor to structure (aka architect) systems, relationships and activities to get intended legal results. The opportunity this workgroup had is to surface the important and potentially outcome changing factors upon which legal determination of use case by use case roles depend. The purpose of creating a sound basis for assigning any/all potentially applicable legal roles to parties in use cases is chiefly to deliberately define and design the legal relationships, rights, responsibilities and results. Ok, so beyond writing a lot of blah blah words, here is what I can commit to for input to the next legal group meeting: I commit to publish a roles and definitions wiki page that is cross-referenced/cross-linked to the use cases we have so far and - more importantly - where the group can continue compiling named roles and other defined terms. Each term will be at an HTML anchor point to simplify and streamline identification of the meaning people are using and to provide a "ready to use" resource for popping in the eventual set of terms and meanings chosen by the group for use in a final set of legal use cases and corresponding recommendations. Thanks, - Dazza | Sent from my iPhone | Please Forgive Typos _________________ | Dazza Greenwood, JD | CIVICS.com <http://civics.com/>, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza(a)CIVICS.com | Biz: 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 On Aug 21, 2015, at 12:01 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: AI: Dazza and Eve: Coordinate on producing 2 or 3 candidate distinctive use cases that flesh out the AS possibilities, non-vertical-specific and identity-federation-agnostic.

2 1

Fwd: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review
by Eve Maler 22 Aug '15

22 Aug '15

Here’s something called a “trust framework” that looks a bit different from what identity federation (or, possibly, access federation) folks might have in mind, but is very interesting. OTA does good work. If anyone is interested to reach out to them in a more formal fashion around UMA synergies, or would like to coordinate on comment collection, let me know. Eve > Begin forwarded message: > > From: Joni Brennan <joni(a)kantarainitiative.org> > Subject: [KI-LC] Of Possible Interest - OTA IoT Trust Framework Public Review > Date: 21 August 2015 at 12:26:51 PM PDT > To: "LC(a)kantarainitiative.org" <LC(a)kantarainitiative.org> > > Dear LC - the Online Trust Alliance has put out a IOT Trust Framework for public review. I believe the paper is 5 pages (for a send of the scope of review). > > OTA has invited Kantara to comment on the paper. > > https://otalliance.org/iot-trust-framework-submission <https://otalliance.org/iot-trust-framework-submission> The deadline is Sept 14th. OTA would be happy to provide your members a briefing or webinar. > > If WGs / DGs have particular interest we are happy to review organizational liaison opportunities as well. > > Best Regards, > > Joni Brennan > Kantara Initiative | Executive Director > email: joni @ kantarainitiative.org <http://kantarainitiative.org/> > > Connecting Identity for a more trustworthy Internet - Overview <http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351> > > > > _______________________________________________ > LC mailing list > LC(a)kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/lc Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Greetings
by Nick Roy 21 Aug '15

21 Aug '15

Hello, UMAnitarians, This is a quick note of self-introduction. My name is Nick Roy - a few of you know me from InCommon stuff. I'm a technical director at InCommon, and I started working there in early June. Before that I worked in identity management at Penn State and The University of Iowa. I'm interested in UMA for a few reasons. We're looking at how it fits in to a consent manager that Ken Klingenstein is working on, and I'm personally interested in OpenID Connect for its usefulness in delegation, mobile apps, and API authorization. Best, Nick -- Nick Roy Director of Technology and Strategy, InCommon Internet2, Denver (GMT -6:00)

1 0

Text affecting #163 (public info), #164 (error code returned) -- and even #168 (ticket in JSON)?
by Eve Maler 21 Aug '15

21 Aug '15

In discussing how to implement our decision on issue #163 last week for how to add the WWW-Authenticate header to success responses in addition to error responses when the client presents no access token, we realized that: 1. The API correctly might want to return 300-class responses in addition to 200-class responses (that is, it’s entirely up to the API what “success” means for it). 2. As long as the response contains the WWW-Authenticate: UMA header and the relevant AS location and ticket info, we don’t much care what HTTP status code is used, because this is enough to tell the client what to do next. 3. If we broaden the text to allow any status code at all instead of 403, it’s sort of non-breaking (barring the “other responses by 403 are undefined” wording that’s in there now) — noting that this also allows a 401. (Hello, issue #164. :-) This resulted in the following wording: https://github.com/KantaraInitiative/wg-uma/commit/b784e6c33e45c02b267ad6b2… “It SHOULD respond to the client with a response that MUST include the "WWW-Authenticate" response header field with the authentication scheme "UMA", providing the authorization server's URI in an "as_uri" property in the header, along with the just-received permission ticket in the body in a JSON-encoded “ticket” property.” - What do we think of this wording? - If we like this wording or something similar... 4. Once we got to this point, I felt increasingly uncomfortable with leaving issue #168 to a later major version because of point no. 1. It’s crystal-clear that the API (which could just be a web app) might want to return a web page or a graphic or whatever. How do you return a JPEG along with a JSON body with a ticket in it? This issue seems not just “critical”, but “blocking”. The downside seems large, the upside seems large, and it seems like a low-impact change to the spec and implementations. The discussion in that issue seemed to be going in the direction of returning the ticket as part of the WWW-Authenticate header. - Are we willing to choose a “breaking” solution along these lines in the patch release? - If we’re not, would we be interested in a “non-breaking” solution along the following lines? “SHOULD provide the ticket in ticket=“ticket-value” in the header, or in the body in a JSON-encoded "ticket” property but the latter is deprecated”. Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

2 6

Issues
by Maciej Machulak 20 Aug '15

20 Aug '15

Hi all, Since we have not covered all the issues today, I include links to commits. Some were not yet covered - e.g. 172. Please review if you have a chance prior to the next call. https://github.com/KantaraInitiative/wg-uma/commit/c66e54a2ff435d4f3c1c1d97… https://github.com/KantaraInitiative/wg-uma/commit/05461d2a45defc9c65c0e1b5… https://github.com/KantaraInitiative/wg-uma/commit/8b99c122a38779733101b06f… https://github.com/KantaraInitiative/wg-uma/commit/1196c74190c87a4dbb0597e8… https://github.com/KantaraInitiative/wg-uma/commit/5c76f22d043bc99109cfef53… Also 1 comment: https://github.com/KantaraInitiative/wg-uma/issues/146 Cheers, Maciej -- Maciej Machulak email: maciej.machulak(a)gmail.com mobile: +44 7999 606 767 (UK) mobile: +48 602 45 31 66 (PL)

1 0

Draft minutes of UMA telecon 2015-08-20
by Eve Maler 20 Aug '15

20 Aug '15

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2015-08-20> Minutes Roll call Quorum was reached. Minutes approval tbs Trust elevation TC writeup reviews and trust elevation/ABAC generally Andrew wants a half-page, and it's hard to keep it that short! Please review and shorten. Is the permission ticket an essential concept for trust elevation, or not? Step-up authentication is one mechanism; non-uniquely identifying, but nonetheless trusted, claims are another that seems special to UMA ("CBAC"). There's a conversation <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150810/0056…> going on about the role of software statements and OIDC in trust elevation. Mike has been following this. NIST has an ABAC "building block" under review; Bill Fisher has reached out to offer a conversation with UMAnitarians. Eve will coordinate. Restricting GitHub editing Do we need to worry about this? The upside is total IP protection. The downside is the pain of making all WG participants get GitHub accounts (a pain to the people) and become collaborators on the repo to submit GitHub issues (a pain to the repo admins). Current sensibility is positive. Legal subgroup report We've been in massive use-case collection mode. The APAC sync folks had interest and asked about the big thread. We hope to start mappings to legal concepts very soon. Andi expresses a hope that specific jurisdictional legal requirements won't impact the specs. E.g., US healthcare examples often don't apply to UK and Europe. Adrian would like to focus at some point on adoption strategy, apart from specific legal strategy. We can cast our eye over lessons learned and release strategy. Issue resolution work We cleared about half the outstanding items in the spreadsheet and in the issues list. AI: Maciej: Tweak spec text related to #147, #170, and #172, and close issues as appropriate. AI: Eve to send email to WG links highlighting newly proposed #163 text, which impacts #164 as well; WG to discuss before next week. AI: Eve to send email to WG discussion topic around #168; WG to discuss before next week. AI: Maciej, Eve, and Andi: Do issue assignments before next week. AI status AI: Thomas: Review the charter for potential revisions in this annual cycle. AI: Sal: Investigate IP implications of formal liaison activities with other Kantara groups with the LC, and ultimately draft an LC Note as warranted. AI: Gil: Edit the UIG to add Ishan's content and excerpt it for Eve to add to the FAQ, pointing everyone to the UIG. AI: Sal: Fill out IDESG form to have UMA adopted as a recommended standard for use in the IDESG framework. AI: Mike: Write SCIM protection case study to highlight client claims-based use case. AI: Maciej: Write as many sections for the UIG as he can. AI: Justin: Write a UIG section on default-deny and race conditions. Attendees As of 30 Jul 2015 (pre-meeting), quorum is 7 of 12. (François, Domenico, Sal, Thomas, Andi, Phani, Robert, Maciej, Eve, Arlene, Irwin, Mike) Eve Andi Arlene Mike Maciej Thomas François Non-voting participants: Adrian James Sarah Scott Jin George Regrets: Mark Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Notes from APAC-friendly UMA WG sync 2015-08-20
by Eve Maler 19 Aug '15

19 Aug '15

Attending: Eve, Gil, Allan, Colin Agenda: - "The very long thread” on legal use cases Eve was driving at “negative use cases”, to get at the points where things go wrong and legal experts are needed. E.g., what happens if Bob gets access outside Alice’s stated policy? Mark is intending to map use cases to consent receipts. Adrian is keen to explore Alice-run/built AS variants. - UMA release schedule update We have all hands on deck for working on the patch release, and we’re on track for our stated timeline. We refactored the non-backlog issue list. - UMA Dev update Save the date: A kickoff call is planned for that WG on Sep 9 (in APAC time zones). - GitHub repo hygiene Eve is thinking about requiring collaborator status to submit GitHub issues (that is, “closing" the repo). Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com

1 0

Legal Use Case - User Managed vs. Controlled Access
by Mark Lizar 19 Aug '15

19 Aug '15

Pushing the penny forward an inch. As a follow up to the MVCR, there are it seems, some legal considerations that surround the application of policy in terms of what takes precedent, the privacy policy, the terms of use policies. As well, liability around who owns, controls and manages the data is also critical and needs to be clear. T A simple way to start putting this all together is to look at applying the MVCR roles ( that are anchored in ISO 29100 “roles") as an overlay to Adrian's (and any other) UMA use cases to address the legal questions and topics that arrise. To get things going here are a couple of items and their flows for the legal eagles. . A. Data Rights Ownership; User Managed Access Vs. User Controlled Access. (see use case below) B. Are T&C’s subjected to a Privacy Policy? Does the legal chain of authority that leads to the provisioning of roles and privileges, for access to personal attributes, start with the privacy policy for enrolment, then the terms and conditions? For example: 1. In the MVCR their is an undiscussed assumption that the privacy policy which provides the consent is counted as the primary contract for the use of personal information so the service provider may then use the personal information. At which point, The service provider uses the PI provided with the consent and then enrols the service user with a secondary policy, the terms and conditions, which Alice needs to contractually abide by, to use the service. As the requirement for a privacy policy and consent is legal infrastructure, and the T&C’s is organisation specific, the T&C’s are subjected to the privacy policy. i.e. legal requirements trump the business requirements in a court of law. 2. In regards to the above Issue 2 . What are the legal connotations - I.e. If a user blocks access to a PII resources (using EU law), the terms for that service might be that the service is stopped. But, the user may be required by the contract to keep paying for that service according to the contract and licence agreed too, and the service may be legally required to keep the user data while still charging for the service. (of course this is over simplified) i.e. the org indemnifies themself by give the functionality to users to manage the access to a copy of the user data the org controls. But in a very privacy by design way. The point being, this would appear to be different UMA Legal Flows than the user (in control of her own data) licensing access to the use of an attribute using UMA, which seems to me, like a different legal flavour of UMA all together. (closer to the UMA Health Flow) I.e.. Alice can turn on and off access to all or just a single attribute at any time in any scoped context. 3. Legal Flow/Use Case: User Managed Access Vs. User Controlled Access. UMA profile that is of two flavours Flavour A. Alice controls access to her own PII, authorises access using UMA to personal profile Flavour B. Alice Manages Access to her own PII . Using UMA installed behind a company siloed (and own Company copy of PII that the user maintains) that runs UMA so users can have more functionality through this silo. Note: this is the difference between the user being the data controller or the user being the data subject. Who controls and owns the data rights? if the service user is also the data controller, then data protection and privacy laws are effected in that the liability and policy for protecting the data lies with the service user, and the liability or contract/license for the usage of the data lies with the company. - this would be a different policy structure, with a consent directive and UMA, for orgs to agree too. Like a Personal Privacy Policy (PPP) to cover the different liability. liability of being a data controller no longer applies the same way as data protection liability is moved (reduced, or changed into another form) if the data subject is owner/controller of the data and its access. For Example: A good example here is in health care where consent directives and laws and frameworks are mature. (i.e. consent and access controls are being bound together already) With Flavour A, Alice Owns and Manages PII, gets to see how many times her personal data (medical records) were accessed, when and by whom Flavour B, Alice, gives away PII - that is already under the T&C’s of service, and owed by the company or institution. in the second circumstance she does not get to see how many times her data was accessed or even what the live status is of her active consents and medical data usage, unless she pays a fee to the Experian like company that owns them. With the MVCR based authorisation log Alice knows that her permission and access to her data should line up to the purpose of the sharing, the permission to access data, and the specified purpose of the active consent the company now maintains for her This would be a very helpful tool for alice to quickly understand medical sharing policies Without clarity between UMA Flavour A & B, does UMA have the opportunity to be : incredibly good (the good guys), because Alice is in full control of their own data incredibly bad, because Alice thinks she has control of a copy of their data. Or that another service provider, that she is forced to trust, has her best interests at hear. should their be a different flavour of UMA (in terms of legal considerations) that designates between A & B? Can their be a flavour of UMA that is both A&B? The MVCR - Binding A & B Together A consent receipt is being developed as a tool that will help bind consent and legal requirements to access roles and policy rules for sharing data. The MVCR is designed to make explicit the policies and notice requirements to make binding these together legitimate and understandable - i.e. this can be used to tie the role of data subject to the liability of access controls and vice versa For example the various frameworks that are used in the space of consent and access control can be added to a receipt. In this scenario, we would see Alice is at a hospital in the US Alice consents to provide PII to hospital for medical treatment Alice gets a consent receipt On receipt is UMA Icon and a HIPPA icon linked to legal requirements, or maybe just a field for a URI that links directly to the PPP, which has all the links and info needed for Alice’s medical records and consent directives (from her AS) Every test or comment can be then linked to her PPP and available for the next health data context This receipt under info sharing would have the PPP Icon, the HIPPA TrustMark icon, and the UMA icon all linked to the audit, enforcement and complaint processes that all of these frameworks require. In parallel to the US health System The UK’s heath care system is the reverse and has the same problems but for different reasons it is a universl health care system, where it costs the infrastructure money to provide medical services. (as oppose to the US) where the infrastructure makes money by providing medical services. In the UK you (the patient) are unable to see if you have consented to sharing PII, with whom you have shared, what medical records you have with Sensitive Medical Data spread on computers ranging from win 95 and up. An UMA enabled doctors office in the UK should be able to receive consent, use the medical data from the US and provide seamless service. So how would a consent receipt look like if it was used to bind ths A Consent Receipt extend the MVCR by: Adding UMA Framework Adding PPP (Personal Privacy Policy: Like a Consent Directive) police requirements Adding HIPPA: Add UK Jurisdiction profile and Medical PII profile to the consent requirements, add these processes at point of consent or enrollment at UK health care centre. These might all appear as ICONS of the above listed to the receipt and managed by 3rd parties operating the trust frameworks for the above elements. Mark > On 10 Aug 2015, at 18:36, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: > > Ok Eve, I'm on it. Looking forward to see the negative cases. > > Hi Mark, do you have any additional use cases to consider? > > Thanks, > - Dazza > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ > | Dazza Greenwood, JD > | CIVICS.com <http://civics.com/>, Founder & Principal > | MIT Media Lab, Visiting Scientist > | Vmail: 617.500.3644 > | Email: dazza(a)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 > | _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > On Mon, Aug 10, 2015 at 3:44 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: > Hi Dazza— Please feel free to send links and updates to the list. I have an action item to work on additional use cases (“negative” ones), and health use case patterns definitely aren’t the only ones we want to consider (nor am I positive that Adrian has captured all of those). Mark may want to contribute some too. And we probably want to spend more than one week on reviewing and understanding them. :-) > > Eve > >> On 10 Aug 2015, at 12:12 PM, Dazza Greenwood <dazza(a)civics.com <mailto:dazza@civics.com>> wrote: >> >> Update - As promised, I put the draft mission, use cases and other background materials on the current GitHub wiki and am UMA-customizing a basic "how to use GitHub issues and wiki pages - for lawyers" faq. >> >> Are the use cases from Adrian solid enough to work on and reflect the business case(s) you need to focus on? Also, do these use cases correctly and completed highlight the UMA functions and flows or is anything off base, incomplete etc? >> >> Anything else needed before next meeting? Should probably send links and ask people to contribute or think about something. Minimally, I'd suggest maintaining some focus on the use cases for now, to ensure an apples to apples anchor for legal conversation and to provide a double check basis for mapping stuff people say from legal to tech and vice versa. >> >> Thanks, >> - Dazza >> >> | Sent from my iPhone >> | Please Forgive Typos >> _________________ >> | Dazza Greenwood, JD >> | CIVICS.com <http://civics.com/>, Founder & Principal >> | MIT Media Lab, Visiting Scientist >> | Vmail: 617.500.3644 <tel:617.500.3644> >> | Email: dazza(a)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> >> >> On Aug 10, 2015, at 2:59 PM, Eve Maler <eve(a)xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: >> >>> I created a (really huge) swimlane and a pro/con list, and a bit more... I ended up writing a recommendation. You can find the whole thing linked from here: >>> >>> https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h… <https://docs.google.com/document/d/1OsIqPbVNx66vypnCzjxoFjX0AHCD_rEmgP8Q-5h…> >>> >>> Eve >>> >>> Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> >>> >>> _______________________________________________ >>> WG-UMA mailing list >>> WG-UMA(a)kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> >>> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma> > > > Eve Maler | cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl(a)gmail.com <mailto:xmlgrrl@gmail.com> > >

4 12