UMA telecon 2016-09-01

Owned by Eve Maler
Last updated: Sep 09, 2016

UMA telecon 2016-09-01

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-08-16 
  • Review latest editors' draft specs
    • Core is up to 01
    • RSR is up to 00
    • UMA refresh/saved consent/persisted claims token?
  • Client awareness of scopes and set math
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2016-08-16: APPROVED by unanimous consent.

Logistics

Eve will move next week's call to Friday, same time. Sorry in advance for the hassles!

Review latest editors' draft specs

  • Core is up to 01
  • RSR is up to 00
  • UMA refresh/saved consent/persisted claims token?

The AAT, as was (in today's UMA), has been awkward because it forces early binding of the RqP/AS relationship, it forces (for all practical purposes) the RO's AS to have a persisted account for the RqP, and it forces the RqP to have an identifier at this AS. It's rather too centralized and too soon. But removing the AAT is too lossy because the notion of capturing the RqP's approval has gone away. Then again,  ...

John W calls the token thingie we're trying to build a "nightclub stamp" vs. a heavier credential like a passport or just a typical login credential. The AS can make the saved preference as light (e.g. it doesn't have to have a local login at all, or force its creation immediately at old-AAT time) or as heavy (it could impose it relatively soon) as it needs to. It can be longer than a "login session" because it's supposed to be static and attached to the lifetime of an RPT (or whatever we end up calling an RPT).

Justin's latest email seems to be saying that the AAT couldn't possibly let the RqP authorize the pushing of specific claims, only let them authorize the pushing of any claims willy nilly. Let's find out if things could be any different in the future. (See the "wide ecosystem challenge analysis" doc.)

How do we solve this without reinventing "backwards UMA" at Alice's AS on Bob's behalf? Ideally, if Bob actually has an AS protecting his (say) attributes/identity claims, then an UMA-protected UserInfo endpoint could simply handle Alice's AS (as a claims client/RP) making requests for that information. But in the circumstance where Bob doesn't have an AS, Kathleen is asking where his delegation/consent should be stored. Are we just talking about a lightweight persistence of his preference for convenient UX reasons? If this is consent by Bob for the client to send claims, is "delegation" a better term?

We do want to be sure Bob has a good experience, because onerous interaction experiences could force him to give up and seek out "worst practices" for access granting/data sharing with Alice. Adrian asks: Could sharing through a pseudonym or through non-uniquely identifying information be possible? In short, yes, depending on what policy condition/trust elevation capabilities an AS has decided to provide, and depending on the use cases needed.

(we ended the formal call and continued discussing for a bit)

Today, the spec text only accomplishes:

  • Subsequent token endpoint usage by the client
  • ...for "pushing of claims"

Design questions for next time:

  • Theoretically, we could add something about the opportunity to have the AS interface specify the exact claims that it needs, though the requirement for the client to push only those claims would be in the realm of the AS "telling on the client" after the fact vs. enforcing the client's actions in the moment! Do we want to do that?
  • Do we also want to add the ability to "save consent" about all the interactive stuff the user either "just did" or "is about to do", or both? And if so, do we want to say anything about the order of such operations, or make clear that the AS can do whatever ordering it wants, or say nothing at all about the order?

Finally, why can't the AAT cover all such interactive approvals as well, as the current V1.0.x spec wording suggests? With the new draft wording, the notion of an "authorization interface" that encompasses the interaction between the AS the the RqP admits a more formal way to describe the RqP's approval that we maybe overstated as being under the authorization API before in Sec 1.3.2. Also, Ishan notes that with this new token thingie, we're back up to "three tokens". So what are the pros and cons of the previous three-token model vs. the new one?

  • PAT/RPT/AAT: Could use straight OAuth to gather the RqP's authorization. But required RqP authentication, and needed to do it up front as soon as the RqP showed up to the AS. This made true "wide ecosystem" use cases a challenge (though this isn't the only barrier to them).
  • PAT/RPT/new thingie: (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.) This paradigm doesn't actually reduce the number of tokens. But we believe AAT removal simplifies UMA and aligns it more closely by leveraging the token endpoint vs. having an RPT endpoint, defers RqP engagement with the AS, and lets the AS choose whether or not to use an authorization/consent saving/account management model with RqPs. There may still be dragons in the design of the new thingie that we don't know about.

Simple descriptions of "Bob's experience" before and after (comments welcome):

  • AAT:
    Alice shares something with Bob.
    Through his client app (which already has client credentials at Alice's AS), he attempts access.
    Depending on the ecosystem and Alice's policy conditions, the process could be as compressed as "Bob already has an account at Alice's AS because everyone in the ecosystem is required to have one, his AAT is created in some implicit fashion (e.g. SAML assertion flow), and any needed claims are automatically pushed as required", or as onerous as the following:
    1. If no account at AS (or at a suitable IdP the AS accepts for a federated login): Create one 
    2. Complete OAuth/OIDC (social login-style) flow to approve client to use this AS
    3. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals)
  • New thingie:
    Alice shares something with Bob.
    Through his client app (which already has client credentials at Alice's AS), he attempts access.
    Depending on Alice's policy conditions, whether trust elevation involves interaction at all, and whether Bob's authorization to will be persisted, the process could be as compressed as "Bob never does anything at the AS, and claims can be pushed totally silently without Bob having an overt relationship with the AS because that's been dealt with out of band" or as onerous as the following:
    1. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals)
    2. Potentially complete a form approving specific client-pushed claims, vs. "any claims the client needs to push to effect access to Alice's stuff" (as noted above, not sure if this is enforceable vs. just monitorable)
    3. Complete a "save consent" interaction at the AS (likely requires a local or federated login account creation first for persistent claims storage [NOTE added 2016-09-09: See next week's minutes for important correction])

Link to the slides Eve showed: Webinar from May 2015 (see slide 15).

Client awareness of scopes and set math

See 2016-06-02, 2016-06-16, and 2016-08-04 notes. Last time we said: "Let's discuss client registration for scopes more next time."

Ha. (smile)

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. Robert
  4. Eve
  5. Jeffrey
  6. Mike
  7. Sarah

Non-voting participants:

  • John W
  • Kathleen
  • Ishan
  • Adrian

Regrets:

  • Maciej