March 2017 - WG-UMA - mailman.kantarainitiative.org

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

Use OpenAPI JSON for Resource Registration?
by Mike Schwartz 03 Mar '17

03 Mar '17

This conversation today about whether to add "description" made me question if we have the right approach for resource registration. I opened this issue to track the idea for using the OpenApi JSON format (Swagger): https://github.com/KantaraInitiative/wg-uma/issues/288 Perhaps instead of creating a whole "registration" API, we should just be documenting how to make this information discoverable? As a point of reference, Google publishes the scopes for it's API's: http://gluu.co/google-scopes - Mike

2 2

Closing RReg issues: #273: Remove reference to "user" in List Resource Descriptions
by Eve Maler 02 Mar '17

02 Mar '17

Hello all-- Please respond to these email threads before Monday's ad hoc if you can! https://github.com/KantaraInitiative/wg-uma/issues/273 Please see below for the notes from today, and weigh in. ==== >From UMA telecon 2017-03-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02>: There is a shallow way to treat this issue, and a deep way, and maybe a medium way. 1. A shallow way is s/user/resource owner/. This gets rid of the jarring impact of seeing "user", considering that Mike has implemented RReg for an OAuth-based API protection use case (as in the first bullet of the RReg Intro), using the client credentials grant. 2. Another shallow way (in addition to #1 <https://github.com/KantaraInitiative/wg-uma/issues/1>, presumably) might be to require OAuth for protecting the RReg endpoint, which requires providing a resource owner context. 3. The deep way might be something like absorbing the entire RReg spec into the UMA Core spec, if we think it's truly incompatible with OAuth and OpenID Connect use cases generally. 4. A medium way might be refactoring the RReg spec to draw the dividing line in a different place, such as having RReg merely provide the bare bones of the API, and having Core provide extension properties to do all the "policy-setting-relevant" work, such as the name, icon_uri, and description fields. This would lengthen Core kind of significantly, but keep an interesting RReg module. Eve and Mike aren't crazy about #4 because it's invasive and really lengthens Core, and it isn't proven yet that RReg as it stands isn't relevant to all three of the technologies or others yet to come. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Closing RReg issues: #270: Resource Registration Document: 'uri' should be an array / examples
by Eve Maler 02 Mar '17

02 Mar '17

Hello all-- Please respond to these email threads before Monday's ad hoc if you can! https://github.com/KantaraInitiative/wg-uma/issues/270 There was some discussion of this in the previous email thread <https://groups.google.com/forum/#!forum/kantara-initiative-uma-wg> (please ignore the discussion in that thread of what became issue #277, the stuff about registering multiple resources at once, which we discussed today). We're specifically talking about the uri field in the resource description doc <https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> here. As it happens, Gluu has found it useful to be an array, and already implemented it this way through need. And Mike is bringing up the notion of allowing wildcards that would have meaning, though he acknowledges the semantic complexity this brings. In the thread, James questions the use cases for this. I'm not presenting a list of options for this one -- have at it. :-) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Closing RReg issues: #31: Optimizing for resource "baskets"
by Eve Maler 02 Mar '17

02 Mar '17

Hello all-- Please respond to these email threads before Monday's ad hoc if you can! https://github.com/KantaraInitiative/wg-uma/issues/31 This is one of our very oldest issues. In the meantime, as the most recent comment in the issue thread hints at (and we even discussed further today <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02> in the context of issue #277), in UMA2 we've done a heck of a lot of work on set math and the resource/scope ecosystem, such that -- for example -- the RS is able to request multiple permissions if it sees fit based on what groups of resources the client is likely to want access to, and we even recommend that this be part of the API documentation. This doesn't have to be based on any special knowledge of what policy-setting opportunities actually exist at the AS, but special public-API profiles could ultimately result in extra-smart AS's doing something knowledgeable with the information. (We and the HEART group have talked about this some.) So, some options are: 1. Do nothing normative and count this as well covered by existing mechanisms and recommendations for profiling - Discussion: We have a way for the RS to handle complex resource structure now, without the AS getting involved. It potentially limits sophisticated policy options, unless a profile is being used that makes the AS "smarter" or a third-party extension is used that adds to what the RS is passing in. 2. Invent some mechanism for enabling the RS to teach the AS explicitly about complex resource structure - Discussion: This could enable cross-AS interop features and additional policy-setting options. But it's invasive to the current design, and maybe it's better to let the need percolate up through more experience. (E.g., maybe a graph structure vs. hierarchy is best. :-) ) 3. Or some other option(s) I'm not thinking of yet?... My proposal: *Option 1*. This is because the discussion points for both 1 and 2 led me in a direction of waiting for communities of interest to show the way. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

02 Mar '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-02-23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-23>: APPROVED. Logistics - Last 90-minute meeting is next Thursday; shoot for quorum so we can vote on WG drafts. - Interest in ad hoc early next week? Eve can do anytime Monday morning PT. Mike and Justin can as well. Let's make it 8:30-10am PT. *AI:* Eve: Put the ad hoc on the calendar. UMA V2.0 work #277 <https://github.com/KantaraInitiative/wg-uma/issues/277>: Conceptually, should we make it possible to register multiple resources at once so as to align the capabilities of registering resources and requesting permissions? Otherwise, an RS might have to register three resources in three calls, and then it would get to request permissions "in bulk" once. Per the discussion about resource registration timing in the UIG, in some use cases, the two steps could be very close together. Gluu actually has already implemented bulk registration as a kind of extension, based on the logic of calling them "resource sets" and there being a many:many relationship between resources and policies through scopes. George points out that the answer really depends on the use case (a la the UIG). For use cases for #1, where the RS is using wildcards the AS doesn't understand, the RS only registers one resource. For use cases for #2, for a Share button there would be only one resource, but for "relationship-driven graph DB sharing" you could have many many resources. For use cases for #3, it might be a finite low-ish number as we anticipate for FHIR. (E.g., each of the use cases in the GDoc <https://docs.google.com/document/d/1jZ1Hua2jM5x4lcpN9URaAv9nGuP_d0hX54a_H5V…> imagining RS permission requests for various APIs gives us a way of imagining finite numbers.) Given that there could be a lot of RReg API work in cases of "what do we do about rollback if some of the bulk registrations don't work but the rest do?", acknowledge the fact that we've left this unoptimized for now, and give ourselves room to add a batch registration endpoint later. This is an explicit question we could ask during "last call". *AI:* Eve: Start a "last call" question list, including the RReg optimization question and the RReg applicability to OAuth and OIDC question. Add this to the UIG. *AI:* Eve: Extend the discussion in the UIG of resource registration timing with the above discussion. #271 <https://github.com/KantaraInitiative/wg-uma/issues/271> and #272 <https://github.com/KantaraInitiative/wg-uma/issues/272>: First of all, we need some security considerations around sanitizing all such text (including the existing human-readable text fields), to ensure there's no active scripting in there. We don't currently have that; we only have it for the icon URIs. What does sanitizing mean? It seems ill-defined in the case of natural-language text being displayed. *AI:* Eve: Insert language about "sanitizing", pointing to a non-normative example of such action, such as this <https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat…> (from George); Jin points to this <https://cwe.mitre.org/data/definitions/20.html> as the vuln. Next challenge: Resource description documents have an RO context, and the RS is basically responsible for doing any L10N before the human-readable strings get to the AS; not our problem for I18N. But the human-readable strings involved in a scope description do have this problem. Do we want to suggest the OIDC-style "hash trick"? We discussed this in the email around #269 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/FUBJaMXQgoE…>. Justin likes the normative language in RFC 7591 <https://tools.ietf.org/html/rfc7591#section-2.2>better. George suggests making this being a "developer-readable" mechanism only. We agree that it's the right pattern to have both the name and the description fields for both. We prefer the dynamic client registration definition of the I18N/L10N mechanism, and will point to its mechanism by reference for both the resource and scope name and description fields. 7591 already covers the circumstance of "any human-facing fields", so we don't have to add that. #276 <https://github.com/KantaraInitiative/wg-uma/issues/276>: What's already in the spec shows that this can be closed. #269 <https://github.com/KantaraInitiative/wg-uma/issues/269>: Note that OIDC's discovery doc already has scopes_supported, which, if filled with URIs, enables static discovery of an UMA scope description document if you want it to. So a closed ecosystem of the sort James mentioned in the #269 thread <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/FUBJaMXQgoE…> could be handled this way. (And in the decision just above, we already have an I18N mechanism.) So option 4 from the email thread is the current best option on the table: "Change even more to say that scope description metadata is possible to standardize, publicize, and reference through a URI, but there is no expectation of run-time resolution by the AS; rather any customization of policy condition setting interfaces with respect to scopes is, um, out of scope." So far, most implementations are only handling the simple strings, while one implementation is drawing the relevant text at run time. Since there's a way to do it statically but machine-readably, let's drop the MUST. Clear consensus on this. #273 <https://github.com/KantaraInitiative/wg-uma/issues/273>: There is a shallow way to treat this issue, and a deep way, and maybe a medium way. 1. A shallow way is s/user/resource owner/. This gets rid of the jarring impact of seeing "user", considering that Mike has implemented RReg for an OAuth-based API protection use case (as in the first bullet of the RReg Intro), using the client credentials grant. 2. Another shallow way (in addition to #1, presumably) might be to require OAuth for protecting the RReg endpoint, which requires providing a resource owner context. 3. The deep way might be something like absorbing the entire RReg spec into the UMA Core spec, if we think it's truly incompatible with OAuth and OpenID Connect use cases generally. 4. A medium way might be refactoring the RReg spec to draw the dividing line in a different place, such as having RReg merely provide the bare bones of the API, and having Core provide extension properties to do all the "policy-setting-relevant" work, such as the name, icon_uri, and description fields. This would lengthen Core kind of significantly, but keep an interesting RReg module. Eve and Mike aren't crazy about #4 because it's invasive and really lengthens Core, and it isn't proven yet that RReg as it stands isn't relevant to all three of the technologies or others yet to come. AI: Eve: Send out dedicated emails about #273 and #31. Attendees As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Sal 2. Andi 3. Eve 4. Mike 5. Cigdem 6. Sarah Non-voting participants: - Justin - Dean Grannes - new participant - George - Jin Regrets: - JohnW - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Introduction
by Dean Grannes 02 Mar '17

02 Mar '17

UMAnitarians, Thank you for letting me attend your meetings, though I am a little late to the party, now that the 2.0 spec is out. I am new to the security field, having spent my time until recently in the areas of microprocessor design and validation. I recently started studying OpenID Connect and UMA, and learned of this working group while reading whatever I could find about the UMA spec. This foray into a completely different discipline is challenging and exciting, and I look forward to participating in the working group, initially mostly listening and learning, and eventually contributing as I am able. I will join today's meeting as a non-voting (and non-speaking, as my headset has no mic) attendee. Thanks, Dean Grannes

2 1

Reminder: UMA Legal calls start up again this Friday!
by Eve Maler 02 Mar '17

02 Mar '17

- *Fridays,* 8-9am PT - Screen sharing and audio: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/ Calendar Let's use *join.me/findthomas <http://join.me/findthomas>* for *both* screenshare and audio (note: I haven't changed the calendar entry regarding this yet). *Agenda:* Reviewing deliverable #1 from Tim R, which lays out sample use cases and legal considerations. He's able to join us for the first half-hour. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0