- WG-UMA - mailman.kantarainitiative.org

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