For some more context, when we discussed this on Aug 7 https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/JP303iN2_p... : - We discussed how telling the requesting side exactly which claim values are needed may be a privacy risk (re-motivating our original decision for leaving claim hashing in the "extension" bucket, and perhaps motivating some AS's to choose parsimonious hinting approaches overall -- but not, I think, directly relevant to #340). - We talked about the AS trying to guess whether the client wants to try again is not the right approach, and agreed it's definitely up to the client. This is relevant to #340 in a sense, but could potentially apply both to a client receiving a Deny-semantic response and an Indeterminate-semantic response. (The slightly edited wording around need_info in the draft to be published shortly, "The client has the opportunity to use the hints as guidance to succeeding in a future attempt", reflects the relationship of hints to the client's choice. - We didn't *clearly* discuss the Deny semantic and our rationale for not having it (though Cigdem said *"regardless of this [forward-looking] 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""*). Recall that we agreed to remove not_authorized on Apr 17 http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-04-13?s... (hmm, not that long ago) as part of our OAuth error rationalization. At that time we did say denial should use invalid_grant because the client wouldn't care, but it seems there's been some water under the bridge since then and James has introduced reasons the client might potentially care (in this case, relationship to the AS's policy decision-making actions and conceptual alignment with other well-known access management models). Possibly also relevant is that need_info gives a 403 (Forbidden), and not_authorized also gave a 403, whereas invalid_grant gives a 400 (Bad Request). On balance, I think we have enough new information/context to reopen this issue (which impacts #350). Finally, note that we have actually backed off of invalid_grant as being appropriate for *"[if] the client is not authorized to have these permissions added"*, wording that still appears there, but I think that wording needs to be removed at this point based on the #340 decision already made, or even if we reopen it! Effectively, we have undone part of our decision of Apr 17, proving the point about water under the bridge. :) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Aug 16, 2017 at 8:36 AM, James Phillpotts < james.phillpotts@forgerock.com> wrote:
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-cor e-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#authorization-failure).
Cheers James
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma