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

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

Agenda for UMA telecon 2017-08-17
by Eve Maler 16 Aug '17

16 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-17 Date and Time - *Thursdays, 9-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 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…> - 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? - 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…> - Email from Wednesday said: - #347 <https://github.com/KantaraInitiative/wg-uma/issues/347>: UMA should not presume to know when scope is not an error (Grant Sec 3.3.4) -- This has to do with whether we should be in the business of definitively saying "it's not an error" when the client hasn't pre-registered for a scope it's requesting from the token endpoint. Please read the thread. - #348 <https://github.com/KantaraInitiative/wg-uma/issues/348>: No means no! (Alice's right to revoke) (Grant Sec 3.6) -- This may be easy to decide if we think Alice's instructions to an AS mean that it's supposed to revoke all available tokens (assuming it's capable to do so), including refresh tokens. This could warrant a security consideration somewhere. - #349 <https://github.com/KantaraInitiative/wg-uma/issues/349>: Undefined behaviour if submitted RPT for upgrade is invalid or expired -- Error path for RPT upgrading? - #342 <https://github.com/KantaraInitiative/wg-uma/issues/342>: Security considerations could be made clearer (Grant Sec 5.2) -- The most efficient way to tackle this one would be for me to get offline help, e.g. from Justin, Cigdem, and/or others. - Email thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/GAvlOCQLH…> from Wednesday on #340 <https://github.com/KantaraInitiative/wg-uma/issues/340>, impacting # 350 <https://github.com/KantaraInitiative/wg-uma/issues/350> (closed already but let's reopen based on new info/context) – also note additional edit needed regardless - 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." - 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 340
by James Phillpotts 16 Aug '17

16 Aug '17

Hi all, I'm still concerned that we're not going far enough with our solution to this issue, and to a lesser degree, issue 350 ("No error defined for policy evaluation failed" and "Which error code to return when candidate granted scopes is less than requested scopes"). My concern is that policy evaluation is a crucial underpinning of UMA, and to not cater for a "Deny" response is a major flaw for being able to communicate the result of those policy evaluations. For reference, consider XACML's definition of a policy Decision: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_ Toc325047158 - we cater for "Permit" (return token), "Indeterminate" (need_info), and "NotApplicable" (request_submitted), but not "Deny". Even if we (rightly) don't want to dictate *how* an AS comes to making its policy decision, we need to be able to support all the possible outcomes of a policy evaluation, just like XACML does, and Deny is an important decision to be able to express. Dressing it up as one of the other decisions is not appropriate. I'd like to see the reinstatement of the "not_authorized" error code that used to exist in earlier drafts of UMA2 to this end (see https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html#authorizatio… ). Cheers James

2 1

Draft minutes of ad hoc UMA telecon 2017-08-08
by Eve Maler 16 Aug '17

16 Aug '17

Attending: - Eve - Cigdem - Mike - Sal Non-voting participants: - James - Justin We have quorum for this call. #352 <https://github.com/KantaraInitiative/wg-uma/issues/352>: James notes that only the resource registration endpoint needs the PAT, because at that time you don't yet have resource IDs (which carry resource owner context); the other two protection API endpoints involve resource IDs, which could convey the necessary RO context and could use the client credentials grant instead, avoiding the need for ROs to refresh PATs. But for anyone who hates "forever tokens" of whatever sort, they will have to bother users. That's the tradeoff. Justin opines that using the client credentials grant is tantamount to using an API key. Eve suggested to a colleague who brought up this challenge: "The PAT does need to serve as an "offline" type of OAuth access token (which is a typical situation for them, perhaps the preponderant one). We've only given guidance that the RS has to manage TTL to ensure the outcome of keeping the PAT alive; see the FedAuthz spec <https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.…> and the HEART profile <http://openid.net/specs/openid-heart-uma-1_0-2017-05-31.html#rfc.section.3.…>. If the RS can't get a permission ticket, it gives this error <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#permi…>: a 403 Forbidden and "Warning: 199 - "UMA Authorization Server Unreachable". The RS could then, in the "competitive space", take this opportunity to initiate some refreshing action such as send a notification to the RO and ask them to re-consent to the pairing with the AS. Does that sound like a reasonable approach? If so, worth describing in the UMA Implementer's Guide <http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui…> ?" Cigdem points out that the PAT represents the RO's agreement for the RS to serve in this role with the AS's various endpoints, and it doesn't seem right to protect its various endpoints in different ways. Eve points out that this is relevant to the legal framework effort, since we're mapping technical artifacts to legal devices right now. The RO could revoke the PAT and that would mean the RO doesn't want the RS to use that AS for those resources anymore. James: Good point. Since this has been brought up, it seems, multiple times we should go back to saying a bit more in FedAuthz Sec 5.1, e.g. provide rationale and point to the UIG for some suggestions about what to do. *We have consensus for no change, but enhancing the explanation (editorial).* (Note to Legal subgroup denizens: We should look at drawing a line between Grant and FedAuthz, for hygiene. PAT is FedAuthz only.) #341 <https://github.com/KantaraInitiative/wg-uma/issues/341>: Eve's proposal: Keep the MUST, so that the AS always hands out a ticket, and provide some UIG suggestions about "competitive space" options for hinting. Justin points out that the client always has the choice anyway to discard the ticket and treat things as "terminal", doing a fresh resource request later (even immediately later). James would like a standard way of saying "Don't try again until...." Do we need to invent that hinting mechanism? If we do, Justin (and Eve) still advocate that the ticket be a MUST. Justin points to the OAuth for Devices spec, which has a hinting parameter we could make use of: interval <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06#section-3.2> (suitably revised to change from a device code to the rotated permission ticket, and the semantic lines up really closely). Or we could use something like nbf a la JWT, though the semantic is a bit more distant and we don't have implementation experience with it for this purpose. We like keeping hints OPTIONAL. We should also add security considerations text to Grant Sec 5.6 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#ticke…>, explaining that given that request_submitted use cases involve polling intervals, the ticket has to last long enough to give the client a chance to poll. Also, text should be added to Grant Sec 3.3.6 pointing to Sec 5.6 and mentioning that the ticket might last longer in this case because of the requirements of the request submission to the RO. #343 <https://github.com/KantaraInitiative/wg-uma/issues/343>: Should we just mention the OAuth errors, or explicitly list them? Eve would like to list them for searching purposes. The OAuth for Devices <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06#section-3.5> spec (Sec 3.5) just calls out to the OAuth codes. This seems sufficient. We have consensus. #344 <https://github.com/KantaraInitiative/wg-uma/issues/344>: We agree with the thread conclusion. These are editorial instructions. #345 <https://github.com/KantaraInitiative/wg-uma/issues/345>: Justin says it's not invalid_request as Eve argued in the issue thread, it's actually invalid_grant because the bits and bobs of the grant request were wrong. This is an original OAuth "Bad Request" rationale. And of course the AS is supposed to document its claim token formats supported in its metadata. Is this worth pointing out explicitly as an example? Alternatively, a need_info/required_claims?claim_token_format hint could be given, if the AS and client have an understanding about hinting. Also, keep in mind that errors can leak information to attackers, and clients need to be treated as largely untrusted (they only have client credentials right up until they get RPTs (at which point they are only partially trusted). If someone forced us to choose between invalid_grant and need_info, what would you choose? In other words, if we want to list out "invalid claim token format" as one of the conditions under a specific one of the error codes, which error code should it be listed under? We have converged on need_info?required_claims/claim_token_format. This gives the exact data the client needs in the most helpful packaging (an error description could still be supplied). *We have consensus.* *AI:* Eve: Book one more ad hoc UMA telecon next Tuesday at 7am PT/9am CT/10am ET/3pm UK/4pm CET. *AI:* Eve: Send emails about the remaining issues and send out revs 07 for review by the ad hoc. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

FYI: Workshop on Socio-Technical Aspects in Security and Trust (STAST 2017)
by John Wunderlich 08 Aug '17

08 Aug '17

This might be of interest to some Kantarians, (even if only to go to Puerto Rico in December). http://stast.uni.lu/ -- 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.

1 0

Agenda for ad hoc UMA WG telecon 2017-08-08 (tomorrow/Tuesday!)
by Eve Maler 07 Aug '17

07 Aug '17

(I think I actually got the date right in the subject line this time.) We have a special meeting tomorrow (Tuesday) at: 9am PT/11am CT/noon ET/5pm UK/6pm CET http://join.me/findthomas Issues: https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen%20is% 3Aissue%20label%3AV2.0%20-label%3Aprocess Grant: https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html FedAuthz: http://docs.kantarainitiative.org/uma/ed/ oauth-uma-federated-authz-2.0-06.html Tonight I plan to update the issues with our decisions from today. Thanks to all for great progress. BTW, if I'm not mistaken, all the decisions from today were made in an "editorial" direction. Can't guarantee we'll necessarily keep going in that direction, but if all we end up doing is clarifying existing text in the same fashion, I don't think we'd need to do another Public Comment period. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes from ad hoc UMA telecon 2017-08-07
by Eve Maler 07 Aug '17

07 Aug '17

Attending: - Eve - Andi - Cigdem - Domenico - Mike - Sal Non-voting: - John W - Justin - Colin - Mark We have quorum today. #337g <https://github.com/KantaraInitiative/wg-uma/issues/337>: The suggestion is "for failure to cascade", that is, for the token in question (permission ticket and possibly PCT) if seen again to cause the AS to kill the relevant tokens based on it. Justin notes that OAuth's experience trying to mandate this has been tricky. It requires complex long-term storage and management, and could pollute the storage with an attacker's ticket. Thus, he suggests making this just advice as a security consideration. It's essentially a health warning to AS implementers. The challenge is if the *first* appearance was from an attacker, causing a race condition. The following could go in Grant Sec 5.6 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#ticke…>: "If the authorization server has reason to believe that a permission ticket is compromised, for example, because you have seen it before and you believe the second appearance is from an attacker (vs the first appearance), consider invalidating any access tokens based on it." The following could go in Grant Sec 5.3 <https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#sec-c…>: "The PCT is designed to be usable multiple times, so the considerations are different. "If the authorization server has reason to believe that a permission ticket is compromised, for example, if it has been supplied by a client with "impossible geography" parameters, consider not using the claims based on it." We have consensus. #339 <https://github.com/KantaraInitiative/wg-uma/issues/339>: Is it already the case that RS's *can't* use an array if they only have one permission they want to request? That's what our problem is: Our spec language "The body of the HTTP request message contains a JSON object (for a request containing a single resource identifier) *or* array of objects (for a request containing more than one resource identifier)" is ambiguous. Since an RS could knock itself out and put a single object in an array anytime it wants, and the AS would have to deal, we should clarify to something like: "...a JSON object containing *one* XXX or an array of *one or more* XXXs..." We don't strictly have to supply an example of an array with one. Anyone who wants to do it will hunt for the wording giving them the rationale. And our rationale, for the record, is not backwards compatibility (since this is a 2.0) but optimization for requesting single permissions. #340 <https://github.com/KantaraInitiative/wg-uma/issues/340>: For one, it would be helpful to also do #343 <https://github.com/KantaraInitiative/wg-uma/issues/343>, which is to list all the other 6749 errors we're borrowing without changing. In this case, Justin is mentioning unauthorized_client, but that's for a broken grant type vs something else more "semantic". The unauthorized_client error would presumably be for when the client itself (vs the requesting party?) isn't authorized to access this resource. Eve's not so sure that an OAuth error meant specifically for the client shouldn't also apply to the RqP, because OAuth (without the UMA grant) doesn't know about RqPs. Justin and Andi's argument about needing to always reach for need_info (vs a definitive "not authorized" error) is that you can't ever make forward-looking statements about the state of play of policies, claims, and such -- things could turn on a dime. Cigdem notes that, regardless of this logic, it's confusing not to be able to point to some obvious "the requesting side, all of it, isn't authorized to get permissions". Nominally, according to what we say about the OAuth invalid_grant error as interpreted by UMA, that would be it ("the client is not authorized to have these permissions added"). Justin's interpretation is literal: It's just something wrong with the client, not the RqP, and is not based on claims. So sending need_info (again), potentially repeating the same claim hints as before, would be appropriate. Sal agrees. Andi notes that saying "Look, you're not old enough, do better next time" could be dangerous and privacy-destroying. Justin points to his previous work on claim hashing as a direction that was abandoned for the time being, for those reasons. The AS trying to be helpful can be dangerous. We have consensus. The client is the one that needs to determine "we're done here". *Instructions:* Clarify in need_info definition that this is the error to use when the client side does not meet policy. #350 <https://github.com/KantaraInitiative/wg-uma/issues/350>: In this case, if the requesting side didn't satisfy some of the policy, doesn't that equate to a need_info error based on our decision on #340? Actually, by the time you get to step 3 in the authorization assessment, you might have some elements that need "request submitted" treatment and some that need more requesting-side claims. Is there an order necessary between request_submitted and need_info, since the AS could ping the RO on the back channel while telling the client it needs claims, and then return request_submitted later if the RO hasn't gotten back to it? So "one of the four errors" is roughly correct. Let's put a terse Note in the spec discussing this. *Consensus.* *Interest in meeting tomorrow at the same time?* Eve will send an invite and hope for the best. Thanks! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for ad hoc UMA WG telecon 2017-08-06 (tomorrow/Monday!)
by Eve Maler 07 Aug '17

07 Aug '17

We have a special meeting tomorrow (Monday) at: 9am PT/11am CT/noon ET/5pm UK/6pm CET http://join.me/findthomas Issues: https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen%20is%3Aissue… Grant: https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html FedAuthz: http://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h… Please take a look at the open issues and weigh in before getting on the call, if possible. This will help speed our decisions. In several of them I've tried to list options and add some discussion points. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Special Monday meeting is now on the UMA calendar
by Eve Maler 04 Aug '17

04 Aug '17

I've removed calendar entries for next week's Thursday WG meeting (Aug 10) and also the Friday Legal meeting (Aug 11). *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Reminder: Legal telecon tomorrow
by Eve Maler 04 Aug '17

04 Aug '17

http://join.me/findthomas 8am PT/11am ET http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes https://docs.google.com/a/meshfire.com/presentation/d/1I12agEsfaJK3LEiJyROr… *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

03 Aug '17

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-03 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-07-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20>, UMA telecon 2017-07-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27>: APPROVE by acclamation. Schedule for upcoming weeks Eve can't make the Aug 10 meeting. Andi is away next week and the third week out. Domenico is out starting Aug 14. If we had an e-ballot running during the last week of August to approve the specs for a new Public Comment period, voting participants on the call could be available online the week of Aug 28 and the week of Sep 4 (that day itself is US Labor Day). AI: Eve: Send invitation for Monday Aug 7 at 9am PT as a substitute for Thursday Aug 10. Eve should be available at our normal times for the following three weeks; we'll see if we can continue to get critical mass then (if not official quorum). UMA 2.0 work #337b <https://github.com/KantaraInitiative/wg-uma/issues/337>: This harks back to Pedro's comments and Justin's responses about the grant's "agnosticism" to clients. The assumption wording in Grant Sec 3.3 now is: "The client has obtained OAuth client credentials from the authorization server, either dynamically through [RFC7591] or [OIDCDynClientReg], or alternatively through a static process, and is prepared to authenticate itself to the token endpoint if appropriate." Instead we could say: "The client has obtained a client ID or a full set of client credentials as appropriate, either statically or dynamically (for example, through [RFC7591] or [OIDCDynClientReg]). This grant works with clients of both confidential and public types." *We have consensus.* #339 <https://github.com/KantaraInitiative/wg-uma/issues/339>: James misinterpreted the wording in FedAuthz Sec 4.1 and so suggested that the RS should get flexibility: object *or* array at its discretion for a single permission in the request, with the AS picking up the slack. The spec would have to clarify/change the wording and probably add an example of the single-object-in-an-array way of doing things. Reactions: - Removing the object option would have been breaking. This isn't. - Typically, adding "two ways of doing things" would be unattractive (except for backwards compatibility reasons; we did that in V1.0.1 and then, in some cases, removed the old deprecated methods in V2.0). - Any insights from OIDC history? Spec design philosophy has been to make the AS do the heavy lifting – we have exactly the same. #341 <https://github.com/KantaraInitiative/wg-uma/issues/341>: Eve's suggestion in the issue thread was that there are two use cases: synchronous and asynchronous. But what does that mean? She meant that by the time the RO responds, it would be impossible to consider their response during the RqP's session. But the discussion from issue #298 <https://github.com/KantaraInitiative/wg-uma/issues/298> is about how it's not a matter of time elapsed, but use cases where the RO's policy says "ask me every time", such that *not* issuing a ticket at all means that the AS would have "amnesia" when the client returns even after a very lengthy period of time. If it returns directly to the AS with the ticket after, say, several days, ticket in tow, even if all the other necessary claims have expired etc., there might then be a record of the RO having said "yes" and claims-gathering could proceed as required. If we decide to change from MUST return a ticket to MAY, then all the client can do when the AS doesn't return a ticket is obviously to start over at the RS. It turns into a terminal type of error from a continuance type of error. Ultimately, a MUST forces it to be one kind of error, while a MAY lets the error function for two different kinds of use cases. So we have two clear options (probably still adding that the AS should document its type of request submissions regardless?): - Option 1: Keep the MUST, which is a terminal error. - Option 2: Change to MAY, which splits into terminal and continuance errors. UMA logo Deferred. Attendees As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem) 1. Domenico 2. Sal 3. Andi 4. Maciej 5. Eve 6. Cigdem Non-voting participants: - Kathleen - Bjorn Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-08-03
by Eve Maler 02 Aug '17

02 Aug '17

*(Please review new/existing open issues and weigh in before the call!)* http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-08-03 Date and Time - *Thursdays, 9-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-07-20 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-20>, UMA telecon 2017-07-27 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-07-27> - Schedule for upcoming weeks - *Can't meet Aug 10*; substitute another time? - When are people on vacation? - 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…> - We need to work through the open issues, so please weigh in on GitHub if you have opinions - 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." - 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

For UMA legal. How would the licensing on this resource work?
by John Wunderlich 01 Aug '17

01 Aug '17

Judge: Lawyers may need to justify $1.12M fee request for '3 months work' in sex toy case settlement | Cook County Record Source: http://cookcountyrecord.com/stories/511162880-judge-concerns-over-1-12m-law… (via Mr. Reader) Thanks, John Wunderlich @PrivacyCDN Pleez 4give speling errurs, sent from a mobile device. -- 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.

1 0

Exemplary real world use case for UMA
by John Wunderlich 01 Aug '17

01 Aug '17

The advocates in the linked article make a good case why the health records of children with congenital health issues that now survive much longer should be kept for life. But this puts burden on the health information custodians with respect to staying in touch with the adult, respecting their consent directives, and respecting regulatory requirements. How much better would be a patient managed/controlled/owned resource server...? https://www.thestar.com/news/queenspark/2017/07/28/medical-records-of-sick-… -- 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.

3 4