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

Can't make the call today
by John Wunderlich 16 Mar '17

16 Mar '17

John Wunderlich, BA, MBA IAPP Fellow of Information Privacy CISA, CIPM, CIPP/C, PbD Ambassador @PrivacyCDN <https://twitter.com/PrivacyCDN> & Privacist -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

2 1

Upcoming meetings (spoiler alert: no WG call tomorrow)
by Eve Maler 15 Mar '17

15 Mar '17

Let's take a breather from the whole-WG meetings this week, and not meet tomorrow. Instead, All interested to review/test/provide feedback can be doing so at any time. Also, there are auxiliary deliverables we can be fleshing out: - Mike S has an action to kick off some kind of "UMA-enabling an OAuth client" writeup (and/or code?). - I'm hoping to start the proper draft release notes. - If those who have contributed to the Wikipedia entry (in various languages) in the past are willing, it's probably time for some updates. - Justin and Sarah, I've been wondering if it's appropriate to list or link to the HEART use cases from the Case Studies page or similar. Any thoughts? - Is there someone who is interested to take a look at the FAQ and other similar pages to see what else is rusty? The Legal call is on for this Friday. As far as I know right now, both meetings will be on at the regular times next week (for 60 minutes each). It would be great to finish reviewing the legal use cases doc by next week, since we'll be expecting deliverable #2 not long after. I'm unavailable on Thursday March 30 and Friday April 1; I'll be canceling those calls. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

WG last call for the UMA2 specs: please get the word out
by Eve Maler 15 Mar '17

15 Mar '17

Thanks to the ministrations of the Kantara marketing folks, there's a new blog post up here <https://kantarainitiative.org/user-managed-access-group-takes-last-call-loo…>, and it's been tweeted here <https://twitter.com/UMAWG/status/842000948071292929> and FB'd here <https://www.facebook.com/UserManagedAccess/>. Please help spread the word! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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