UMA telecon 2016-09-29

Owned by Eve Maler
Last updated: Sep 29, 2016
5 min read

UMA telecon 2016-09-29

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-09-22 
  • UMA video and IIW
  • Work on UMA.next issues
    • Core is up to 02
    • RSR is up to 00
    • Persisted claims token and other changes – see this difference set
    • Work on set math – see this email thread
    • Getting consensus on all the latest changes and queuing up the next bunch of work
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes

Approve minutes of UMA telecon 2016-09-22 : Deferred.

Work on UMA.next issues

We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.

The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec.

AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes.

The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether."

A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes."

Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners."

Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay.

The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this."

Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?

AI: Eve: Get Justin's input on our analysis and questions.

In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."

(Note and fix typos.)

James had proposed set math as follows:

(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes

The questions for the spec are:

  • What does the RS have to do at API publication time, if anything?
    • There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable)
    • Nothing much more to say about this, probably (we have some editorial notes on it)
  • What does the client have to do at scope registration time, if anything?
    • It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it)
  • What does the RS have to do at permission ticket registration time?
    • In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other
    • This remains to be fully discussed, though we started it at CIS
    • Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 about efficiency of client communications for smart clients)
  • What does the client have to do at RPT request time?
    • How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?
    • In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible
  • What does the AS have to do at RPT issuance time?
    • In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it
    • There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)

 Spec instructions:

  • See above!

Attendees

As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)

  1. Domenico
  2. Sal
  3. Nagesh
  4. Robert
  5. Eve

Non-voting participants:

  • Andrew
  • Scott F
  • Kathleen
  • James

Regrets:

  • Mike
  • John W
  • Andi