UMA telecon 2017-07-27

Owned by Eve Maler
Last updated: Jul 27, 2017

UMA telecon 2017-07-27

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-07-20 

  • UMA V2.0 work:
    • Disposition of Comments/GitHub issues for V2.0/Grant swimlane, FedAuthz swimlane/Release Notes/UIG/Wikipedia/Grant rev 06 (forthcoming)/FedAuthz rev 06 (forthcoming)
    • The Disposition of Comments is the best overall way to drill into what's been done and what remains
    • Please focus on #335, #337, #339, #340, #341, and #342 – and let's get these all done in one session, so please do some homework before the call
    • Candidate motion (let's target next week when we'll have had more time to review the latest decisions): "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
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2017-07-20: Deferred.

UMA 2.0 work

337a: RFC 7519 just says these three claims are optional. (Right now we are being inspired by the claims and not registering for JWT claims specifically.) Cigdem, along with Justin, argued for removal of an explicit statement (as we still do for exp) saying exactly what it means when the permission-level parameter is absent. If we don't say, then Eve's interpretation is that "the AS isn't claiming anything" about that semantic. It's up to the AS, presumably, what it means, but that's part of its prerogative. Mike wonders what AS wouldn't include a value. We already say what happens if it has a value at variance with the permission-level value. If we take away the exp "no-value" statement of "never", then the AS has the incentive to do the right thing in any case (vs, say, deciding on a super-secret nbf value of Jan 5, 2020 at 03:59:53). That doesn't help anyone! Consensus to remove the exp statement.

337c/d: The suggestion is to 1) make it a MUST for the AS to require public clients to register claims redirection URIs (Grant Sec something), with the rationales that it matches 6749 Sec 3.1.2.2 and it's more secure (we have consensus on this), and 2) to request registration of a metadata field to the OAuth dynamic client registration metadata registry (Grant Sec 2). Would we also want to request registration of a metadaata field to the OIDC dynamic client registration metadata registry, or is it all the same? It appears to be the former. We have consensus that adding the metadata field is sensible too, with the rationale that it gives a concrete way to register the URI and removes friction from interoperable dynamic registration. But we do want to check with Justin (who is the designated expert for this metadata registry). This would require a new section or subsection in Grant akin to the AS metadata section.

AI: Eve: Ping Justin re claims_redirect_uri metadata field.

337f: We discussed Cigdem's proposed example, which starts with a resource request of album and a permission ticket containing photo1 and photo2, which adds a level of trickiness that may be distracting for the point at hand. We think the calculation seems pretty simple regardless; the AS is "dumb" with respect to resources, even though scopes are resource-bound, so it does the calculatiion the same way regardless. Only the RS knows resource relationships. The AS does an expansive scope match on the client's behalf because the client is "dumb" with respect to resources.

AI: Eve (hopefully with Cigdem's input): Come up with a hybrid example that has two resources in the permission ticket.

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. Mike

Non-voting participants:

  • James
  • Kathleen
  • Robert
  • Scott
  • Bjorn