- WG-UMA - mailman.kantarainitiative.org

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

25 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 20 Aug '17

20 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

Non-critical but interesting issue #335d: input on claims push/redirect swimlanes?
by Eve Maler 20 Aug '17

20 Aug '17

On issue #335d <https://github.com/KantaraInitiative/wg-uma/issues/335>, with Cigdem's influence, I had concluded that it would be best just to keep Grant Fig 1 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#high-…> (the main grant swimlane) as it is, though with a bit more introduction <https://github.com/KantaraInitiative/wg-uma/commit/815ac195d0b4a419106884da…>. However, I did just create a couple of extra ASCII swimlanes, trying to come up a way to add small swimlanes to the "claims push" and "claims redirect" discussions. I think they, or something like them, may be kinda helpful. Thoughts? Worth putting in the spec somewhere, or maybe the UIG? Or is the critical insight that both of them can start with either 401/new ticket or 403/rotated ticket, which could/should be factored out into a separate diagram? Token endpoint/claims push, showing the two options for responses that may cause the client to push claims: authorization resource client server server | | | |401 response with new permission | |ticket, authz server location | |<-------------------------------------| | | | | OR | | | | | |403 response with rotated | | |permission ticket (e.g. | | |with need_info error, | | |required_claims hint) | | |<--------------------------| | | | | |RPT request with | | |permission ticket (e.g. | | |with claim token) | | |-------------------------->| | Claims redirect, showing the two options for responses that may cause the client to start interactive claims gathering: requesting authorization resource party client server server | | | | | |401 response with new permission | | |ticket, authz server location | | |<-------------------------------------| | | | | | | OR | | | | | | | |403 response with rotated | | | |permission ticket (e.g. | | | |with need_info error, | | | |redirect_user hint) | | | |<--------------------------| | | | | | |Redirect | | | |user with | | | |permission | | | |ticket | | | |<-----------| | | |Follow redirect to authz server | | |--------------------------------------->| | |Interactive claims gathering | | |<- - - - - - - - - - - - - - - - - - - >| | |Redirect back with rotated permission | | |ticket | | |<---------------------------------------| | |Follow | | | |redirect | | | |to client | | | |----------->| | | | |RPT request with permission| | | |ticket | | | |-------------------------->| | *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2017-08-17
by Eve Maler 19 Aug '17

19 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-17 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of ad hoc UMA telecon 2017-08-07 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/JP303iN2_…>, ad hoc UMA telecon 2017-08-08 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/YLS0wIDqR…>: APPROVED by unanimous consent. Schedule for upcoming weeks - *Can't meet Aug 24*; substitute another time? (Domenico and Andi out too) - Can't meet Aug 30; substitute another time? (Domenico out) - Need to do any e-ballots for Draft Recommendations? *AI:* Eve: Schedule ad hoc UMA WG telecon for Wednesday Aug 23 8am (to give precedence to voting participant attendance). UMA 2.0 work #340 <https://github.com/KantaraInitiative/wg-uma/issues/340>, impacting # 350 <https://github.com/KantaraInitiative/wg-uma/issues/350>: Cigdem's comment of Aug 7 came out of Justin's description of need_info. The RO can at any time change the policy; that's the "not being forward-looking" part. But she only understood that because of sitting on the calls and getting that sophisticated explanation. She thinks not_authorized could cover both request_submitted and need_info. But request_submitted translates more accurately to "NotApplicable" in XACML <http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf> (see Sec 5.53). The reason looking at XACML is valuable is that it's a mature authorization architecture, and there are similar ones following similar patterns. "Deny" is a key – one could argue *the* key – semantic of such an architecture. We seem well aligned that NotApplicable maps nicely to request_submitted, where the latter adds a bit more context about the next step the AS will take (ask the RO). What about Deny? Eve wonders if not_authorized with optional "advice" of need_info riding alongside equates best to it? It was troubling her that need_info has a MUST of one or both of redirect_user and required_claims. Its main function in the world was originally intended to be hinting. In removing not_authorized without reexamining this requirement, we have overloaded need_info in a strange way. Andi points out security implications. If the AS says need_info and it returns something without functional hints (IOW, if we try to invent a weird way of using need_info to stand for a "Deny" semantic), that violates the "obviousness of the protocol" standard. [image: (smile)] *AI:* Eve: Doublecheck that the dictated language about using need_info/required_claims?claim_token_format got into the spec correctly. Was our logic in April correct about the client "not caring" why it didn't get the token? We think not, because it will want to know what it did wrong. In fact, that's the entire purpose of having a hinting mechanism. If the client was denied access vs leaving off a request parameter, that seems like an important thing to know. What if we were to "rename" need_info to not_authorized, and soften the hint MUST to MAY? It's not that simple because the permission ticket is required to return. They actually still seem like two different things because need_info maps to an Indeterminate semantic. We have consensus that we should add back an error code that maps to Deny; it would be a terminal error (no permission ticket) and would not provide any hints or advice or anything. What would the need_info semantic be? Cigdem proposes a request_denied error that doesn't leak any information all by itself. Its definition would be exactly as not_authorized was most recently: "The client is not authorized to have these permissions added. The authorization server responds with the HTTP 403 (Forbidden) status code." It maps to Deny. - request_denied: Deny (no ticket) - looks like our recently deceased not_authorized - has to be added to our IANA registration request for error codes - request_submitted: NotApplicable (ticket) - need_info: Indeterminate (ticket) - confirmed that we prefer to make it have some hinting content (redirect_user or required_claims or both) - confirmed that we like our decision about using claim_token_format for correcting incorrect format in the request - issues RPT: Permit (no ticket) As for the impact on #350, if the AS decides not to issue an RPT in the case of fewer scopes than requested, that would be whichever of these errors it thinks is appropriate. Probably not the pre-authorization-assessment errors; those are for syntax blowups. #349 <https://github.com/KantaraInitiative/wg-uma/issues/349>: James has replied in the thread and thinks we may be okay on that. #342 <https://github.com/KantaraInitiative/wg-uma/issues/342>: *AI:* Cigdem and Eve: Work on this together. UMA logo Deferred. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Sal 2. Andi 3. Eve 4. Mike 5. Cigdem Non-voting participants: - Kathleen - James - Robert - John Regrets: - Domenico *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0