- WG-UMA - mailman.kantarainitiative.org

Notes from UMA Legal telecon 2017-03-13
by Eve Maler 13 Mar '17

13 Mar '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-03-13 - Reviewing use cases doc <https://docs.google.com/document/d/1otArZxgjNKCCqnlqswxKqgJ_0TnJOjJ3IywVz2U…> Attending: Eve, Adrian, Tim R, Paul L, John W, Mark L The "Use Cases Deliverable 1b" document (in GDoc form) is now basically trapped in amber, so to speak, and the subgroup might tweak and change for our own purposes, e.g. starting a new version of our primer materials with this content, or editing this doc, but Tim will probably create the other two deliverables owed separately from this one. *AI:* Eve: Convert the "salient factors" to hyperlinks in the doc. The doc starts with legal considerations and use-case desiderata, moves to proposed use cases (which are "hybrid" in that they are as real-life as possible and mix various scenarios), and finally moves to UMA technical considerations that need to be solved. Today, let's analyze the use cases with the thought in mind to figure out whether there's a finite or infinite number of them to capture. Should we "go there" when it comes to things like industrial IoT (IIoT or Industry 4.0)? We probably have to because the topic of national infrastructure and mass transportation with smart sensors has been coming up, and individuals interacting with these, with privacy implications. So we should probably include use cases for them. We got through use case A and part of B. Tim is keen to keep use cases C and F, which might not at first blush seem directly applicable, because of the market need. *AI:* All: Review the use cases doc (asking Eve for commenting privileges as necessary) in preparation for Friday's call. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

UMA Legal: Reminder that we have moved our Friday meeting to Monday instead
by Eve Maler 13 Mar '17

13 Mar '17

Speak to y'all on Monday 10-11am PT, when we will continue to review and analyze the new use cases doc and see what else Tim R might have up his sleeve. :-) By then I'm supposed to have that doc put into a GDoc form for easy review and comment, so please stay tuned for that. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

WG drafts published
by Eve Maler 13 Mar '17

13 Mar '17

https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html https://docs.kantarainitiative.org/uma/wg/oauth-resource-reg-2.0-07.html I'm just reaching out to Kantara folks now to figure out how to start a publicity process... Especial thanks to Cigdem for improving like 25 different spots in Core! :) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-03-09
by Eve Maler 09 Mar '17

09 Mar '17

MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-03-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02>: Andi moves to approve the minutes. APPROVED. Logistics - This is our *last 90-minute meeting* - We plan to vote on our specs as WG drafts (simple majority required) and let them percolate for four weeks as "last call" drafts while we invite people to join the group to finalize them with us and implement them UMA V2.0 work - #288 <https://github.com/KantaraInitiative/wg-uma/issues/288> is open and worth discussing (OpenAPI) The aim of Mike's proposal is to enable those documenting an API to capture, at the same time as they're thinking about describing the API for the audience of client devs, to capture related information. It consolidates what would have been two tasks into one. On the other hand, this rationale only applies if you're using OAI, and it also requires the AS to fetch a bunch of information that's not relevant to it, and deal with a lot of error conditions ditto. And what if it's not a REST API, but a file/folder paradigm with static resources or whatever? Alternatively, what if the RS just used the OAI format as a common format somehow? Look at how long it took us to decide to add the "description" field last week. But then why not SCIM?? (Said in bitter jest...) Positive registration is probably the bigger burden than the actual format being registered. We've now made it a little more implicit how a tightly coupled AS-RS relationship would be done (by doing away with the huge "extensibility profiles" infrastructure), but it's still possible to make more efficient through profiling a "different protocol than HTTP" for doing resource registration. Swagger/OAI is used a lot for API documentation now, and there are a lot of tools for it, but we also have a rationale for all the pieces of the resource description document and scope description document now. It would perhaps be more attractive to extend OAI descriptors property to add scopes to them – but even then, the "customer" of that information is the client, not the AS. *Close this issue with no action* but put on the extension label for future experimentation. - #252 <https://github.com/KantaraInitiative/wg-uma/issues/252> is open and worth discussing briefly regarding how to handle editorially and succession-wise (pointing to the V1 security extension spec – ticket rotation) V2.0 is not susceptible to the attack mitigated by the extension <https://docs.kantarainitiative.org/uma/draft-uma-claims-sec-ext-v1_0.html>. Eve recommends *adding a sentence to Core sec consid. OK.* - #289 <https://github.com/KantaraInitiative/wg-uma/issues/289> (potentially moving a UIG XSRF security warning to Core if necessary) Let's delete the UIG section and *add nothing to Core.* - #270 <https://github.com/KantaraInitiative/wg-uma/issues/270> (URIs as arrays/wildcards) is open but hasn't gotten a lot of support – needs some really good explanation or it will die Now that we separated out issue #277 from this one: A wildcard character is just another character, so if a singleton URI contains wildcards that are known to have special properties only to the RS, great; we're not crazy about giving the AS special wildcard-processing capabilities, though. (This is sub-issue no. 2.) How much are we getting into the game of allowing the AS to use this to be "something else", such as a discovery service? Eve's idea was that the RS could put in both the URL for – say "rev 19" of Core and also the soft link URL for the latest rev of Core. The concern is that it could be abused by the RS. Justin makes the argument that "uri" being meant for more than just display (e.g., true resource discovery), and reaching outside the UMA entity ecosystem, it has greater security and privacy consequences than any of the human-displayable stuff. We have consensus on *removing the uri field* and marking this issue with the extension label. - Regarding having removed claim_token_profiles_supported: In RReg Sec 2.4, *remove "_uri" from all the URI examples. Also, have two examples: One without uma_profiles_supported, and one with (using ...IDToken).* - Shall we simply close #277 <https://github.com/KantaraInitiative/wg-uma/issues/277>? (not doing CRUD rreg in bulk) It's *closed, with no action*; it's only individual RReg for now. We'll see what happens in the next four weeks. - I proposed in email <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/$2331%…> that we close #31 <https://github.com/KantaraInitiative/wg-uma/issues/31> with no action – it sort of wants an “extension” tag, but really it is just open for anyone to make extensions if they need them Eve proposes Option 1 from her email (*close with no action*). James groks. [image: (smile)] Let's close, put the extension label on it, and put the email proposal into the issue. - #273 <https://github.com/KantaraInitiative/wg-uma/issues/273> is open (did the shallow s/user/resource owner/ fix) Eve did the minor editorial change. Now we just need to go out there and see how possible it is to apply RReg to OAuth and OIDC. Let's add a section to the UIG about this (should have been done a while ago). WG draft vote if we're ready A good motion on this would be something like: "Approve revisions of the UMA V2.0 Core and Resource Registration specification drafts as Work Group Draft Specifications for publication and review, as amended by the specification revision notes in UMA telecon 2017-03-09 and any non-normative copyedits proposed by Sunday, March 12." *MOTION:* Andi moves and Mike seconds. APPROVED by unanimous consent. These will be Core rev 20 and RReg rev 07. Discuss review period logistics We have a couple of open issues that have a new "process" label. Eve plans to work on the Release Notes proper, which have a paradigm of explaining things "per software entity" and in terms of "what changed since the last release". But we also have an opportunity to do lots of other stuff, like describing how an OAuth client dev can understand what an UMA-friendly client's needs are. *AI:* Mike: Write up a draft of what it looks like to develop an UMA-friendly client from an OAuth client dev's perspective, and then get Justin's feedback. *AI:* All: Please review the new section on set math in the UIG. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Andi 3. Eve 4. Mike 5. Cigdem Non-voting participants: - Justin - James - John W - Jin Regrets: - Sarah - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-03-09 (attendance is important -- thank you)
by Eve Maler 09 Mar '17

09 Mar '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-09 Date and Time - *Thursdays,* final *special meeting time: 8:30-10am PT* - Screenshare *AND* dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-03-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02> - Logistics: - This is our *last 90-minute meeting* - We plan to vote on our specs as WG drafts (simple majority required) and let them percolate for four weeks as "last call" drafts while we invite people to join the group to finalize them with us and implement them - UMA V2.0 work: - 2016 roadmap <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> / GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> (all issues to be kept here for the duration!) / dynamic swimlane <http://www.websequencediagrams.com/files/render?link=Pu0sP0Oe2kjKc2WgdKZd> - Core is up to 18 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-18.html> (updated) and RReg is up to 06 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-06.html> (updated) – hope to do an big editorial pass for a Core 19 and RReg 07 before the call - #288 <https://github.com/KantaraInitiative/wg-uma/issues/288> is open and worth discussing (OpenAPI) - #252 <https://github.com/KantaraInitiative/wg-uma/issues/252> is open and worth discussing briefly regarding how to handle editorially and succession-wise (pointing to the V1 security extension spec – ticket rotation) - #270 <https://github.com/KantaraInitiative/wg-uma/issues/270> (URIs as arrays/wildcards) is open but hasn't gotten a lot of support – needs some really good explanation or it will die - Shall we simply close #277 <https://github.com/KantaraInitiative/wg-uma/issues/277>? (not doing CRUD rreg in bulk) - I proposed in email <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/$2331%…> that we close #31 <https://github.com/KantaraInitiative/wg-uma/issues/31> with no action – it sort of wants an “extension” tag, but really it is just open for anyone to make extensions if they need them - #273 <https://github.com/KantaraInitiative/wg-uma/issues/273> is open (did the shallow s/user/resource owner/ fix) - Other issues are tagged with "process" or "ediorial" and can or must be done later - WG draft vote if we're ready - Discuss review period logistics - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Core rev 18 and RReg rev 06 are out
by Eve Maler 09 Mar '17

09 Mar '17

https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-18.html https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-06.html I've been doing some big copyediting reviews and hope to have another wave of revisions up before Thursday's call, but most of the substantive issues have been cleared, and I wanted to get these out for review now. Agenda for Thursday out in a second. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 3

Notes from UMA ad hoc telecon 2017-03-06
by Eve Maler 06 Mar '17

06 Mar '17

*Attending:* Eve, Justin, Domenico, George, Kathleen towards the end, possibly Dean on the screen *#284* <https://github.com/KantaraInitiative/wg-uma/issues/284>* if George has any further input; otherwise we can make this a last-call thing* Refresh tokens exist at all to enable access tokens to be short-lived. Separately from this, we’ve discussed how an UMA-enabled AS could leverage a short TTL strategy for RPTs. What does it mean for an AS to downscope an RPT based on a client requesting scopes at the token endpoint? Our current “MAY implement upgrading” text is clear and binary, and recommends documentation. We don’t currently say anything about downgrading. If a refresh token is returned, how would it be interpreted? It’s an OAuth refresh token, so — as Justin says — he’d interpret it to mean he could only get “the same” RPT or potentially one less powerful. But normally, OAuth allows a client, during a refresh flow, to include scopes for the purpose of downscoping. Justin suggests allowing scope values there but saying that the effect is undefined; this would be better than disallowing values. *AI:* Justin: Pull request to write up a new Section 3.10 describing refresh token flow profiling for purposes of UMA grant interaction, with a cross-ref from Section 3.6.6. With this, we can close #284. *#282* <https://github.com/KantaraInitiative/wg-uma/issues/282>* to see (briefly) if there's sufficient support for the suggestion, as we've been discussing it for a while* The key “business ecosystem” question is: Which way would we want to bet on whether an API publisher would be willing to request different permissions dynamically? Eve and Justin are pretty certain they wouldn’t. Justin is concerned about greater and greater complexity of the proposal, and hence premature optimization. The RS would need to keep tracking more information in order to optimize others’ experience. Are we right in thinking that, since we’re talking about enriching the information sent to the RS through a JSON format, this could be an experimentation that grows into a V2.x addition? We believe so. So there’s room to play with this later if we discover pain in some deployments. Let’s close without action for now, but anyone could take it up on their own initiative at any time if they see the need. Let’s create a label for all the potential extension work. *#254* <https://github.com/KantaraInitiative/wg-uma/issues/254>* (hashed claim discovery)* This could have implications for the whole need for protected discovery and so on. But on the other hand, is it an enabler for rainbow table discovery? So it needs some proper thinking and work. So this gets the close-without-action and extension labeling. *#267* <https://github.com/KantaraInitiative/wg-uma/issues/267>* (extensibility profiles)* Justin recommends excising Section 5 entirely. OAuth says it’s only about HTTP stuff, and ACE is still doing its thing, after all. What about adding just a sentence or two in the HTTP Usage section explaining why it’s important to still produce the on-the-wire artifacts (mainly tokens and their contents/introspection objects): it’s to support the legal toolkits. The rationale for this rationale :-) is that it connects the technical and legal worlds from the spec side. Justin disagrees. She will talk to Tim R to see if this is actually helpful, and if not, won’t put it in. Plan is to excise Section 5 in any case. *#263* <https://github.com/KantaraInitiative/wg-uma/issues/263>* and **#119* <https://github.com/KantaraInitiative/wg-uma/issues/119>* (claim token profiling)* Typo: In Sec 6, s/for for/for/ Justin agrees the whole “hybrid” thing makes no sense. But since the client is the primary audience of the ID token, we’re back to: - Narrow ecosystem: AS=IdP, in which case, it can be entirely “out of band” of UMA because the client already has the user (RqP) context. Eve notes that even in narrow ecosystems, which G2C seems to have a bunch of, interop can be valuable because of independent implementation. And then potentially in future phases, the vertical sectors might want to start combining. The question is, since we no longer have an AAT for “stateful” versions of same, should we pick a better string for the OIDC “stateless” version, namely, http://openid.net/specs/openid-connect-core-1_0.html#IDToken as Mike suggests? - A medium ecosystem where the audience field pretty much only works if the AS has pre-established trust with the RqP’s IdP — we don’t know of these in the wild yet, but Eve knows of some future-phase projects that may require these. Justin asks the question: What behaviors would change on the client’s part if the AS were to declare support for an OIDC mechanism vs., say, a SAML or PKI?? or whatever mechanism. - Wide ecosystem — Eve and Justin both expect these to use the interactive flow, which would bootstrap a PCT We could: 1. Just switch the string in the example, and not define it as a claim token profile or an UMA profile. 2. Define a claim token profile. 3. Switch the notion of claim token profiles to UMA profiles. Eve will try #1 for now, and issue #119 about IANA registries is pointless. :-) We can soften the language around “claim token profiles” and say it can be another kind of UMA profile if you feel the need. *#260* <https://github.com/KantaraInitiative/wg-uma/issues/260>* if anyone wants to argue for pulling cascading authorization servers forward into V2.0 at this time* At this point, not having had others besides Mohammad weigh in, we’ll close without action and put the new extension label on the issue. *#270* <https://github.com/KantaraInitiative/wg-uma/issues/270>* (making "uri" an array, and possibly a wildcard)* Justin feels this adds complexity without commensurate benefit. He doesn’t understand what the additions buy you. Mike may need to flesh out his proposal, and maybe this is in extension-land. Unfortunately, if we did make this an extension, we’d be looking at an unattractive object-vs-array choice because registering one uri now vs. an array later through a different property ?? is awkward. *#288* <https://github.com/KantaraInitiative/wg-uma/issues/288>* about using OpenAPI for RReg, and I just remembered to label it properly* Justin feels this adds complexity without commensurate benefit. Why not choose SCIM instead? :-) “REST works because it’s a pattern, not because it’s an API.” Sometimes, what you’re protecting is in fact a “true API”, and in that case, perhaps you might want to extend the resource registration document with OpenAPI stuff, but otherwise not. In which case, maybe this is in extension-land too. But if you’re registering photos or whatever, it may or may not be appropriate or a particularly good match. *Shoebox endpoint work…* *AI:* Eve: Put the extension label on this stuff too. *Looking at the kinds of issues we have open at this point, one of the things to consider -- given that we'll be asking people to **join the group in order to give feedback** -- is whether we feel comfortable considering cutting loose a WG draft with "must-fix" issues closed, but keep working on tiny other ones, or what.* Eve shared her “UMA2 Basics” deck with Domenico. He and she will work on adding graphics and other content to it to help convey the changes to people, e.g. authorization assessment and other stuff. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Mar 6, 2017 at 7:55 AM, Eve Maler <eve(a)xmlgrrl.com> wrote: > Almost forgot, for completeness's sake in this thread: Mike S put in issue > #288 <https://github.com/KantaraInitiative/wg-uma/issues/288> about using > OpenAPI for RReg, and I just remembered to label it properly. > > > > *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | > Twitter: @xmlgrrl > > > On Sun, Mar 5, 2017 at 11:50 PM, Eve Maler <eve(a)xmlgrrl.com> wrote: > >> Folks, I apologize for getting this ad hoc into the calendar only now; if >> you recall, we agreed on Thursday that we'd meet on Monday (tomorrow!) >> 8:30-10am Pacific. I *may* get dragged away sooner than that because of >> my delay... (Long story.) >> >> For tomorrow, let's switch back to the open Core issues, and then go back >> to the open RReg issues, in this order: >> >> #284 <https://github.com/KantaraInitiative/wg-uma/issues/284> if George >> has any further input; otherwise we can make this a last-call thing >> #282 <https://github.com/KantaraInitiative/wg-uma/issues/282> to see >> (briefly) if there's sufficient support for the suggestion, as we've been >> discussing it for a while >> #254 <https://github.com/KantaraInitiative/wg-uma/issues/254> (hashed >> claim discovery) >> #267 <https://github.com/KantaraInitiative/wg-uma/issues/267> (extensibility >> profiles) >> #263 <https://github.com/KantaraInitiative/wg-uma/issues/263> and #119 >> <https://github.com/KantaraInitiative/wg-uma/issues/119> (claim token >> profiling) >> #260 <https://github.com/KantaraInitiative/wg-uma/issues/260> if anyone >> wants to argue for pulling cascading authorization servers forward into >> V2.0 at this time >> #270 <https://github.com/KantaraInitiative/wg-uma/issues/270> (making >> "uri" an array, and possibly a wildcard) >> ... >> >> Looking at the kinds of issues we have open at this point, one of the >> things to consider -- given that we'll be asking people to *join the >> group in order to give feedback* -- is whether we feel comfortable >> considering cutting loose a WG draft with "must-fix" issues closed, but >> keep working on tiny other ones, or what. >> >> >> *Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | >> Twitter: @xmlgrrl >> >> >

1 0

Agenda for UMA ad hoc telecon 2017-03-06
by Eve Maler 06 Mar '17

06 Mar '17

Folks, I apologize for getting this ad hoc into the calendar only now; if you recall, we agreed on Thursday that we'd meet on Monday (tomorrow!) 8:30-10am Pacific. I *may* get dragged away sooner than that because of my delay... (Long story.) For tomorrow, let's switch back to the open Core issues, and then go back to the open RReg issues, in this order: #284 <https://github.com/KantaraInitiative/wg-uma/issues/284> if George has any further input; otherwise we can make this a last-call thing #282 <https://github.com/KantaraInitiative/wg-uma/issues/282> to see (briefly) if there's sufficient support for the suggestion, as we've been discussing it for a while #254 <https://github.com/KantaraInitiative/wg-uma/issues/254> (hashed claim discovery) #267 <https://github.com/KantaraInitiative/wg-uma/issues/267> (extensibility profiles) #263 <https://github.com/KantaraInitiative/wg-uma/issues/263> and #119 <https://github.com/KantaraInitiative/wg-uma/issues/119> (claim token profiling) #260 <https://github.com/KantaraInitiative/wg-uma/issues/260> if anyone wants to argue for pulling cascading authorization servers forward into V2.0 at this time #270 <https://github.com/KantaraInitiative/wg-uma/issues/270> (making "uri" an array, and possibly a wildcard) ... Looking at the kinds of issues we have open at this point, one of the things to consider -- given that we'll be asking people to *join the group in order to give feedback* -- is whether we feel comfortable considering cutting loose a WG draft with "must-fix" issues closed, but keep working on tiny other ones, or what. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Followup from today's Legal call: links and resources
by Eve Maler 03 Mar '17

03 Mar '17

Here's a link to my RSAC 2017 session <http://rsaconference.com/events/us17/agenda/sessions/6826-designing-a-new-c…> page, which points to the slides and video. Here's link for the white paper Hannes T shared with me on Data ownership in the context of the European data economy: proposal for a new right <https://www.twobirds.com/en/news/articles/2017/global/data-ownership-in-the…>. (Short answer: It isn't one.) The Internet of Medical Things article <http://www.americanbar.org/publications/scitech_lawyer/2016/spring/the_inte…> I mentioned from SciTech Lawyer is behind a paywall online, but here's the relevant snippet I mentioned on the call: "Who Owns the Data? Users of networked medical devices may not have a clear chain of title to the data collected on the device. The medical device manufacturer of third parties may claim ownership of data by virtue of limitations in the purchase agreement or license for the device or they may have patents, software agreements, or trade secrets that limit what the user can do with the data collected on the device. Healthcare providers can avoid this protential problem by making sure they receive an irrevocable license, granting them exclusive rights to de-idenitfy, aggregate, commercially use, and transfer all data collected by the medical device. ...." (I was thinking that whatever rights are needed, the user/wearer of the device should be the one getting them first, whoever that is, and then the clinician if they're second in line! And building UMA, and our legal toolkit(s), into the permissioning approach would be a good safeguard for the manufacturers to use. :-) ) Finally, I've attached a slightly revised version of the "consent layers" diagram I showed here. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA Legal telecon 2017-03-03
by Eve Maler 03 Mar '17

03 Mar '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-03-03 - Reviewing draft Legal deliverable #1 Attending: Eve, Tim, John W, Colin, Mark L *Logistics:* Since Fri Mar 10 Eve can't meet, we will substitute Mon Mar 13 at 10am PT/1pm ET. *AI:* Eve: Schedule the substitute meeting on the calendar. *Legal deliverable:* Tim has deep experience in identity and authentication law (Virginia and unified US, ++). We are fortunate that he is a passionate legal UMAnitarian! The first section in the doc is about goals. User "management" is about rights to *control* access. An ABA publication came out just today about IoT, addressing topics of data "ownership". Mark L talks about the distinction between Data Protection and Data Control, and UMA is really about reaching the latter. UMA goes beyond most of today's regulations, and that's what's groundbreaking. Tim believes "this could be the most significant legal tool in a thousand years". Access control can have governance and economic functions. Data flow can unleash positive value. Business value and individual value can both be served in tandem by enabling selective sharing. "Diachronic" consent/access control is about allowing ongoing changes and additions of information. Value can increase over time as information is shared. So this concept is directly related to business and individual value. *AI:* Eve: Convert the use case document to GDoc form so we can comment/adjust live. The *Lex Informatica* considerations are about ensuring that our global networks and global flows of data are accounted for. There need to be rules embedded in software and devices. For the "F. Citizen-Facing Government Services" use case, what if we develop an additional use case that matches the OIX Pensions Dashboard use case, which is similar and another live topic of conversation? Parking lot of topics for Tim and the group: - Distinguishing between cases where there's a *hard statutory reason* to disclose data/give access (e.g. GDPR Article 6.1, HIPAA, etc.), and not giving the individual an opportunity to consent and say no (where access is given anyway), and cases where there's an organizational decision to reserve to itself data sharing rights with an opt-in that's not "data control"-friendly - Adding "UMA salient factors" more specifically in the section after the use cases, including possibly proactive "Share" vs. reactive "Access Approval" (Opt-In with Choice) flow options *AI:* Eve: Share RSA talk link, consent layers diagram, the article with the articulation of "no data ownership", and snippets from the article on the Internet of Medical Things. *AI:* Eve: Reach out to Mike Pegman/David Rennie about possibly developing a companion use case for use case F. *AI:* Eve: Reach out to the people who agreed to review the primer a long time ago, and ask them to look at the deliverable as it grows and see what they think (maybe enhanced with our "UMA technical definitions". *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0