- WG-UMA - mailman.kantarainitiative.org

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

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

21 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

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

18 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+note… 2017-08-18 Attending: Eve, Tim, Kathleen, Sal, Colin Quick discussion related to the CIS WG topic of User Submitted Terms and who is the data controller: John introduces the concept of "Two Solitudes". The more we – in our various WGs and specs! – start figuring out exactly how individuals can influence organizations through these mechanisms, we want to ensure that the "resource regulators" and other influencers get the right idea about how all this applies to the privacy entity roles. The UMA and CIS WGs should plan some joint calls to sync, share wisdom, line up questions, and identify points of interaction and interop between specs and frameworks. Let's plan this at the next Kantara Workshop at CIWUSA17. Looking at the new version of the role definitions (Word doc on the screen): *UMA Role 4*: The *Automated Transaction* definition accounts for the fact that these transactions are indeed digital in nature and often automated. So this is an "underpinning" kind of definition. This comes from existing Uniform Law. (Tim's approach is to borrow language from existing laws, so that it's familiar.) He'll add the citations before publication to ensure the text all has the right authority. The *Protected Resource* definition discusses "All data (and then a long list of data and type of content taken from existing law language)...". Do we mean all data, or specific data/content controlled by an RO, available at an RS, and protected by an AS? "Protected resource" is a specific UMA concept, and this is the sort of "magic triad" that makes it a protected resource. Kathleen mentions the concept of "addressable" as a potentially helpful term to ensure we mean the digital and web-ish kind or even IoT-ish kind. Tim thinks that "information" as defined in a particular body of law he knows (which was it? Fiduciary Access Law? it covers assets after someone has died) could be useful. So do we need to enumerate the kinds of information, or can we reuse someone else's definition? We probably don't need to include a notion of "addressable". Maybe something like *"A digital asset (citation) manageable/managed by a RO"*. Boom! The verb there is just to connect the standard meaning of digital asset to our concept of RO that's in this glossary. Hopefully we don't have to worry about actual explicit liability considerations in choosing this verb yet (though maybe we do?). We are thinking that the *Authorization Server Operator* definition should say "authorization server" vs "access server", and then cite UMA Grant because it defines "authorization server", and likewise the *Resource Server Operator* definition should say "resource server" vs "host server" and cite UMA Grant. This "gives authority", so to speak, to UMA's official definitions of these technical terms. Likewise in the fullness of time, we'll want to point to the official UMA definitions of the various technical artifacts. (Note that the only artifacts not defined in the UMA Grant spec (or FedAuthz spec - PAT is in there) would be "client identifier" and "client credentials", and those are in the OAuth 2.0 spec: IETF RFC 6749. This law Tim wants to use expressly covers what to do about digital assets when somebody has died. UMA has relevance in Digital Death use cases (see past IIW notes for lots of work on this!). - Even after the RO has died (this body of law is useful even before that time, though!), *as long as the PAT is valid*, and the RPT and permissions are still valid, then an RqP can still get access. - If the RO does estate planning, then delegation mechanisms could be used at the business logic layer above any one instance of an UMA flow so that a "transfer of protected resource ownership" can be effected. Though the *Data Subject*/*Resource Owner* relationship isn't the same as the *Requesting Party*/*Requesting Party Agent* relationship, we should make sure to have the same kind of "*on behalf of themselves or (the other one)*" construction in the right (other one of the pair). The Legal Relationships section may have been overcome by events; maybe review it for current accuracy, or remove it. Or possibly we'll simply have the "all-singing all-dancing" paragraph ready for inclusion. We do have a Legal call next week. We *DO NOT* have a Legal call on Fri Sep 1. US and Canada people, enjoy the long weekend for Labor Day! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal telecon on Friday
by Eve Maler 18 Aug '17

18 Aug '17

8am PT/11am PT http://join.me/findthomas We won't have Tim with us, but will have his revised role definitions to review and also comments from John in the slide deck. Eve Maler (sent from my iPad) | cell +1 425 345 6756

1 0