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

Issue #354: No error for bad request body in FedAuthz RReg (also PAT handling)
by Eve Maler 04 Sep '17

04 Sep '17

https://github.com/KantaraInitiative/wg-uma/issues/354 Please take a look and weigh in on this new issue as soon as you can (I have already done so in the thread). We do not have a call in which to discuss the issue live this week, so I will plan to draw editorial conclusions from the issue thread unless it seems there's some controversy that needs discussion. After any required editing, I'd like to get our e-ballot under way by next Tuesday morning. Eve Maler (sent from my iPad) | cell +1 425 345 6756

2 2

Revs 07 are here for your review! (attached)
by Eve Maler 01 Sep '17

01 Sep '17

Hi folks— I’m having trouble FTPing the specs onto the Kantara site; I’m attaching them here so as not to delay your ability to review them. Please take your earliest opportunity to do a review, paying close attention to whichever issues you submitted or care most about. You can find the close-to-final Disposition of Comments doc here to help guide you: https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+o… Knowing US and Canada people have a long weekend coming up, let’s make the deadline for review *THIS FRIDAY* (or *first thing Monday morning* if that works for your schedule). I don’t think you should need more than about an hour to read through all this, especially if you focus on key passages of interest. Do please pay special attention to *Grant Sec 3.3.4, Sec 3.3.6, and Sec 5*. If any issues are reported, I will turn around rev 08 drafts by first thing Tuesday morning and then start an e-ballot for Draft Recommendation approval, and then w can get the resulting specs to the Leadership Council for certification for All-Member Ballot. Thank you for your awesome efforts on the disposition of all the comments! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

UMA Legal role definitions, annotated
by Eve Maler 26 Aug '17

26 Aug '17

Please find attached Tim R's final draft of his Legal role definitions document for our review. This is a really excellent piece of work that I'm excited to share with you all! I've put a few new diagrams at the front of the slide deck <https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROr…> that illustrate some of the concepts and relationships herein in a lightweight way. Please consider this draft deliverable #3 to be close-to-final, and provide comments in that spirit. We might very well enhance the definitions that appear here to prepare them for use in any model clause text, but please view this version as the foundation for our legal framework. As such, this would simply be the conceptual basis for such clauses and any other tools. I apologize again for having had to cancel today's call; we had a medical emergency at home that seriously messed with my schedule. Note that we have no meeting next Friday (due to my being away on vacation). However, I will be peeking at email during my absence, so keep those cards and letters coming. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Apologies for the late notice, but Legal telecon canceled for today
by Eve Maler 25 Aug '17

25 Aug '17

Tim, if we can sync up 1:1 later on in the day, that would be great. If people have comments on the diagrams, please send them to the list. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0

Feedback on new #348/#349 language / draft spec status
by Eve Maler 24 Aug '17

24 Aug '17

In yesterday's call we decided to rearrange some text from FedAuthz into Grant and highlight it as privacy considerations. I've done that in this commit: https://github.com/KantaraInitiative/wg-uma/commit/3bea4d67c292d873c752fe52… I'd like to draw your attention particularly to this new passage: "In order to account for modifications of policy conditions that result in the withdrawal of authorization grants (for example, fewer scopes, fewer resources, or resources available for a shorter time) in as timely a fashion as possible, the authorization server should align its strategies for management of these factors with resource owner needs and actions rather than those of clients and requesting parties. For example, the authorization server may want to invalidate a client's RPT and refresh token as soon as a resource owner changes policy conditions in such a way as deny that client and requesting party future access to a full set of previously held permissions." There's now a companion small privacy consideration in FedAuthz privacy considerations like this: "As noted in Section 6.1 of <xref target="UMAGrant" />, the authorization server should apply authorization, security, and time-to-live strategies in a way that favors resource owner needs and action so that removal of authorization grants is achieved in a timely fashion. PATs are another construct to which it can apply these strategies." Your feedback is welcome. My plan is to get revs 07 out in the next day or so for people to review against all our decisions, and then by the end of next week to start a Draft Recommendations approval e-ballot after you've all had a real chance for review. IF ANY VOTING PARTICIPANT WILL BE 100% OFFLINE and unable to participant in such activities in the next couple of weeks, please let me know! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New end-to-end Legal licensing scenario diagrams from Domenico
by Eve Maler 23 Aug '17

23 Aug '17

Please see slides 7 and 8 in the Legal deck <https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROr…> for some new diagrams. Thoughts?... We will have a call this Friday (but not meet next Friday). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2017-08-23
by Eve Maler 23 Aug '17

23 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-23 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2017-08-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-17>: Deferred. Schedule for upcoming weeks No meeting next week; everyone should review the final drafts for consideration in the e-ballot instead. (Justin and Mike are attending the MyData conference, and Mike is talking about UMA (and OIDC) there!) Eve discussed the question of repeating Public Comment review with the LC, and the conclusion was that it wasn't necessary; we are just handling the comments that came in, and there's no need to repeat that long review period. We just need to publish our DoC document properly and proceed. UMA 2.0 work #348 <https://github.com/KantaraInitiative/wg-uma/issues/348> and #349 <https://github.com/KantaraInitiative/wg-uma/issues/349>: Part of Justin's argument about refresh tokens is that they really shouldn't contain claims; their entire purpose is just to be exchanged for access tokens directly, with whatever existing scopes (permissions in our case) are there. However, the wording we picked to reflect this simplicity ended up being somewhat ambiguous: we said "MUST NOT treat...", not "MUST NOT do...". Isn't it the case that the AS should be invalidating tokens – both access tokens (RPTs) and refresh tokens – on the occasion of an *RO's policy change*, not necessarily a client's resource request? Because some policies could have partial effects on RPTs, then the proper effect might be to downscope a token. A "clever" AS (note that policy condition setting is outside the scope of the spec as stated in FedAuthz Sec 1.4.1 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…>, and we already advise documenting capabilities) has choices about how to coordinate policy setting and execute policy decision-making. There's a range of capabilities possible. Note that GDPR has a "right to withdraw consent at any time" and its Recitals talk about "withdrawing consent without detriment". Any implementation that is trying to accede to a data subject's wishes as closely as possible would align with the resource owner's policy changes in terms of timing vs the client resource request, if possible. The ICO draft consent guidance <https://ico.org.uk/media/about-the-ico/consultations/2013551/draft-gdpr-con…> (see page 37) says: "If someone withdraws consent, you should stop the processing *as soon as possible*. In some cases it will be possible to stop *immediately*, particularly in an online automated environment. However, in other cases *you may be able to justify a short delay* while you process the withdrawal." For an expired (but otherwise okay) submitted RPT for upgrade, if the AS is willing to upgrade it, we think it's reasonable for that to be upgradable. We need to say this. For an invalid RPT or any other value for a submitted RPT that is not understandable, that is properly an invalid_grant error or the AS could ignore it. This is just normal OAuth error handling, and we shouldn't say anything about it. Same for an invalid PCT parameter, right? That's another optional parameter. There's already an error for invalid scopes. We decided not to say anything precisely because these two are optional parameters. James proposes that the permission ticket could be *optional* when you're upgrading an RPT, because you're just asking for the same packet of permissions again, just extending the expiry time. Is this a new grant, a new sub-grant of the UMA grant, or what? Is this a replacement for the refresh flow? The use case for RPT upgrading is to allow the client to not have a million RPTs and be able to have more of a big RPT with all the permissions in it. The idea of no-ticket upgrading, we guess, is to pre-emptively refresh the RPT. And since the client is unaware of the fine-grained permissions inside an RPT, it won't necessarily get the benefit of "refreshing" any permissions inside its token without going through other gyrations. Decisions: - We choose this option: Clarify the current wording to explicitly *prohibit* the AS from re-evaluating policy: *"The authorization server MUST NOT perform an authorization assessment calculation on receiving the client's request to refresh an RPT."* - We want to move 99% of FedAuthz Sec 1.4.1 to Grant Privacy Considerations (except for the PAT part). The PAT part should remain in FedAuthz, and it should be part of the Privacy Considerations. - Currently it says "Supplying an existing RPT gives the authorization server the option of upgrading that RPT instead of issuing a new one (see Section 3.3.5.1 for more about this option)." We should add "Supplying an existing RPT *(which MAY be expired)* ..." This is sufficient for indicated that this isn't an error condition. - Create a new issue for James's idea of making the permission ticket optional when upgrading the RPT, and put the "extension" label on it. #347 <https://github.com/KantaraInitiative/wg-uma/issues/347>: At issue: Whether to allow the AS to decide, on whatever occasions, to reject the client's dynamic request for some scope(s) because the client hadn't pre-registered for that/those scope(s), and generate an error. We think that it's not a terrible overloading of invalid_scope to define/refine it (from OAuth's original definition) to let the AS use it for this purpose along with the other purposes we were already using it for. The Note reads like this: "Note: It is not an error for the client to have requested a scope for which it did not pre-register because RequestedScopes might include that same scope, requested on the client's behalf by the resource server when obtaining the permission ticket. However, if such a scope were requested only by the client at the token endpoint, that scope would not be included in RequestedScopes." Can we simply edit the optional error condition into the error explanation and remove the Note? *Yes.* Decisions: - Remove the "Note" text. - Add to the error conditions as follows: "At least one of the scopes included in the request does not match an available scope for any of the resources associated with requested permissions for the permission ticket provided by the client. *The authorization server MAY also return this error when at least one of the scopes included in the request does not match a scope for which the client is pre-registered with the authorization server*." - Check and try to change from "client pre-registers/ed" to "client is pre-registered" throughout where possible. #342 <https://github.com/KantaraInitiative/wg-uma/issues/342>: Cigdem has sent a fresh PDF to Eve with comments for inclusion. UMA logo Deferred. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Eve 2. Mike 3. Cigdem Non-voting participants: - James Regrets: - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-08-23 (specially scheduled: tomorrow at 8am PT/10am CT/11am ET/4pm UK/5pm CET)
by Eve Maler 22 Aug '17

22 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-23 Date and Time - *Special Wednesday time, 8-9am 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-08-17 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-17> - Schedule for upcoming weeks - *No meeting Aug 30*; use this time to review forthcoming specs preparatory to voting in a WG e-ballot for Draft Recommendations - Candidate motion when we're ready: "Approve UMA 2.0 Grant rev *nn* and FedAuthz rev *nn* as amended by the instructions of UMA telecon 2017-xx-xx as Draft Recommendations and forward them to the Kantara Leadership Council to request immediate certification for an All-Member Ballot as Recommendations." - UMA V2.0 work: - Disposition of Comments <http://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of…> /GitHub issues for V2.0 <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> /Grant swimlane <https://www.websequencediagrams.com/files/render?link=GDUuGPibcbXrR5uWBSQP> /FedAuthz swimlane <https://www.websequencediagrams.com/files/render?link=tGft5o5ErGvUWj4X3o-O> /Release Notes <http://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes> /UIG <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> /Wikipedia <https://en.wikipedia.org/wiki/User-Managed_Access>/Grant rev 06 <http://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html> /FedAuthz rev 06 <http://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h…> - Issue #348 <https://github.com/KantaraInitiative/wg-uma/issues/348>: No means no: see issue thread and also new email <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/11q_GHWlE…>: decide today (related to issue #349 <https://github.com/KantaraInitiative/wg-uma/issues/349> regarding invalid/expired RPTs – okay to upgrade them?) - Issue #347 <https://github.com/KantaraInitiative/wg-uma/issues/347>: We say it's not an error when client doesn't pre-register for a scope it requests, but should this be left flexible or made a definite error? See issue thread - Optional on issue #335d <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/HgQcreOa4…> : add new swimlanes to spec or UIG? <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/HgQcreOa4…> - UMA2 logo discussion (defer till we're in All-Member Ballot) - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #348 (no means no): refresh flow(s) and options
by Eve Maler 21 Aug '17

21 Aug '17

https://github.com/KantaraInitiative/wg-uma/issues/348 James and I met this morning to analyze this issue a lot more closely; *please see the thread* for detail. In short, we noticed a) lack of wording clarity (is the AS actually prohibited from re-evaluating?), b) the fact that RPT upgrading is a kind of refreshing of the RPT envelope but with definitive re-evaluation (and the option of providing a PCT as input), c) a plethora of circumstances where re-evaluation on refresh might be valuable but also incomplete, and d) the distinction between token-level lifetimes (good to keep short) and permission-level lifetimes (could be long). I said I would send a note suggesting options to consider, so here they are: - *No change* to the current wording in Grant Sec 3.6: "The authorization server MUST NOT treat the client's request to refresh an RPT as if it were a request for a new RPT requiring an authorization assessment calculation." - Clarify the current wording to explicitly *prohibit* the AS from re-evaluating policy (currently we're not sure it achieves that). - Change the current wording to allow the AS to *choose* whether to re-evaluate policy (acknowledging that it may have incomplete inputs with which to do so). - Change the current wording to *require* the AS to re-evaluate policy (acknowledging that it may have incomplete inputs with which to do so). - *...Sub-option on all: *Add more explanation and and possibly security considerations text. Please share your thoughts before Wednesday's meeting! (*Our Thursday call has been moved back to Wednesday at 8am PT.*) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Issue #349: invalid/expired RPTs for upgrade - close to closure/editorial proposal?
by Eve Maler 21 Aug '17

21 Aug '17

https://github.com/KantaraInitiative/wg-uma/issues/349 Please see the thread and add your thoughts. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0