UMA telecon 2017-08-17

Owned by Eve Maler
Last updated: Aug 17, 2017
4 min read

UMA telecon 2017-08-17

Date and Time

Agenda

  • Roll call

  • Approve minutes of ad hoc UMA telecon 2017-08-07, ad hoc UMA telecon 2017-08-08 

  • 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/GitHub issues for V2.0/Grant swimlane/FedAuthz swimlane/Release Notes/UIG/Wikipedia/Grant rev 06/FedAuthz rev 06
    • Email from Wednesday said:
      • #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: 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: Undefined behaviour if submitted RPT for upgrade is invalid or expired -- Error path for RPT upgrading?
      • #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 from Wednesday on #340, impacting #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

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of ad hoc UMA telecon 2017-08-07, ad hoc UMA telecon 2017-08-08: 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, impacting #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 (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. (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: James has replied in the thread and thinks we may be okay on that.

#342:

AI: Cigdem and Eve: Work on this together.

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

Â