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_pY>, ad hoc UMA telecon 2017-08-08 <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/YLS0wIDqRz0>: 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