- WG-UMA - mailman.kantarainitiative.org

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

Agenda for UMA telecon 2017-03-02
by Eve Maler 01 Mar '17

01 Mar '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-03-02 Date and Time - *Thursdays,* *special meeting times continuing: 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-02-23 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-23> - 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? - 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 17 <https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-17.html> (updated before the ad-hoc-that-didn't-happen) and RReg is up to 05 <http://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-05.html> (no change) - Work on open RReg issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>; see also relevant emails, many presenting options to choose from and some with people weighing in – let's take issues in this order: - Discuss #277 <https://github.com/KantaraInitiative/wg-uma/issues/277> – see also Re issue #270 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/kxQo7-4_JQY…> (for its commentary about issue #277...) - Discuss #271 <https://github.com/KantaraInitiative/wg-uma/issues/271> and #272 <https://github.com/KantaraInitiative/wg-uma/issues/272>– see also Re issues #271 / #272 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/HUCnn9BGkSM…> (not much additional in the message) - Discuss #276 <https://github.com/KantaraInitiative/wg-uma/issues/276> – see Re issue #276 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/Dq-kgH3MkI0…> - Discuss #269 <https://github.com/KantaraInitiative/wg-uma/issues/269>– see Re issue #269 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/FUBJaMXQgoE…> - Discuss #270 <https://github.com/KantaraInitiative/wg-uma/issues/270>– see Re issue #270 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/kxQo7-4_JQY…> - Discuss #273 <https://github.com/KantaraInitiative/wg-uma/issues/273>– see Re issue #273 <https://groups.google.com/forum/#!msg/kantara-initiative-uma-wg/dc7m1MOceQw…> (we've talked about using "last call" to seek OAuth/OIDC usage of the RReg spec) - Discuss #31 <https://github.com/KantaraInitiative/wg-uma/issues/31>– leave on backlog? close without action? decide on some action? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies
by Eve Maler 28 Feb '17

28 Feb '17

I'm sorry for not making it to the call today, and for the confusion with Colin trying to run the call in my stead (thanks, Colin!). Not feeling well today. I'll try and line up RReg decision-making in email as best I can for Thursday. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

282: Facilitate chatter reduction at the RS
by James Phillpotts 27 Feb '17

27 Feb '17

All, I've added a comment to issue 282 to follow on from discussion after I dropped off the call last week: https://github.com/KantaraInitiative/wg-uma/issues/282 Cheers James

1 0