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

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