Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

UMA telecon 2016-09-09

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-09-01  
  • Logistics
    • Meeting next week?
  • Work on UMA.next issues
    • Core is up to 01
    • RSR is up to 00
    • UMA refresh/saved consent/persisted claims token logic – refer to 2016-09-01 notes
    • UMA grant flow requirements – refer to 2016-08-18 notes
    • Client awareness of scopes and set math – refer to 2016-06-02, 2016-06-16, and 2016-08-04 notes
  • AOB

Minutes

Roll call

Quorum was not? reached.

Approve minutes

Approve minutes of UMA telecon 2016-09-01: ?

Logistics

Meeting next week? No, we are not meeting next week.

Work on UMA.next issues

  • Core is up to 01
  • RSR is up to 00
  • UMA refresh/saved consent/persisted claims token logic – refer to 2016-09-01 notes
  • UMA grant flow requirements – refer to 2016-08-18 notes
  • Client awareness of scopes and set math – refer to 2016-06-02, 2016-06-16, and 2016-08-04 notes

Persisted claims token

Let's use this name for now and do the big "names for everything" roundup when we get to it.

MITREid Connect implemented the original UMA RPT as a "true" OAuth access token – so, nothing special about the "UMA bearer token profile". And since UMA Core didn't say anything one way or another about refresh tokens, they didn't implement that.

Pros and cons:

PAT/RPT/AAT/(no RPT refresh token):

  • Uses straight OAuth to gather the RqP's authorization.
  • Requires implementation of the AAT.
  • Requires ReqP authentication.
  • Requires that authentication as soon as the RqP shows up to the AS.
  • AAT interferes with "wide ecosystem" use cases (though this isn't the only barrier to them).
  • Has an "extra" endpoint (RPT endpoint).

PAT/RPT/RPT refresh token/persisted claims token: (Note that the AAT really is gone, though there are a few rogue mentions still in the spec and there's more surgery to do, e.g. a true "UMA grant" flow specification needs to be written.)

  • Requires implementing a minimum of two tokens. (Optionality.) A full implementation could implement the PCT as well.
  • One fewer endpoint overall. (Simplicity.)
  • This paradigm doesn't actually reduce the number of tokens.
  • Don't know yet about all aspects of PCT design. Is a new invented thing.

Andi notes that if we've got "consent" tokens (mindful that we want to avoid that word!) floating around, we want to think about auditability. So it's time for a good pow-wow with the CIS WG, and also for discussing "notification endpoints" and such.

We're agreed that the "PCT" would be best applied for both interactively gathered and pushed claims both. Now, to examine how smooth or complex the RqP interaction could get. We looked at Eve's analysis of how "compressed" or "onerous" the flows could be. Justin notes that the RqP's authorization is not required for the token itself to persist the claims of both categories, so the "onerous" picture in the PCT case isn't really right. In other words, the RqP doesn't need an account at the AS. 't envisions a special claim that represents the RqP's authorization – that is, a claim with special semantics.

Should we have a separate spec for this special claim? It's sort of internal to the AS, so maybe we just define it right in the same UMA Core spec, and don't put it in any standardized registry.

Andi feedback: He'd like a single restatement of what we're trying to solve, why the existing design doesn't solve the problem, and why the new redesign does (we think) solve the problem. What are the security risks? What are the privacy risks? Would PII be leaked? What are the audibility and traceability characteristics? What are the performance characteristics? Let's do swimlanes comparing them. Justin might be able to "build the blasted thing" and Eve can commit to doing the foregoing explanation. We might be tantamount to spec'ing this as well. Let's do all this analysis in email.

Attendees

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

  1. Domenico
  2. Andi
  3. Maciej
  4. Eve
  5. Mike
  6. Sarah

Non-voting participants:

  • François
  • Justin
  • Adrian
  • Kathleen

 

  • No labels