To clarify Justin’s stance on the client providing scopes:

The original UMA idea of the client not knowing the scopes is, in my opinion, a hippie fantasy. It seems very nice that a client wouldn’t have to worry about things like scope and that it could just go do API things and have stuff magically work. In reality, the client needs to know the API that it’s calling — otherwise, it can’t call the API. Part of that is going to be knowing what kinds of actions it *can* take on the API. We’re not talking about just doing a generic GET on a URL, we’re talking about protecting web APIs with interrelated data models that need to be parsed, transactions and processes that need to be managed, and all of that fun stuff. Why would you want to give a read/write access token to a client that can only read? I also contend, and point to existing implementations as straw-man anecdotal proof, that the RS is generally going to cast a wide net or privileges for the client to prevent multiple round trips by the client at the API. The RS needs to guess what the client might want, and practicality tells us that we’re better over-guessing. This isn’t good security practice of course, but it makes things easier for client developers and that kind of usability will, as we know, always win this fight.

I think part of this comes down to a matter of system design philosophy. UMA is trying to automate magical things for the client, but this is a case where the client really doesn’t have to do that much work and is in a much better position to make a statement about what it can do and what it wants to do at the RS. The RS is in absolutely *no* position to make that guess, since it doesn’t know who the client is let alone what its capabilities are. This feels like automation that nobody asked for, akin to WSDL files and SOAPy setups. The RESTful revolution showed us that client developers are happy to do a couple of things by hand if it means the overall setup is easier (and doesn’t rely on automated tooling anymore). 

And let’s also not discount clients talking to multiple resources. Say I’ve got a client that can manage my calendar and my contacts list. My calendar isn’t going to know about my contacts list scope, nor should it. But my client can tell the AS “hey these are two scopes I’m looking for at once”, and it’s up to the AS to manage that kind of cross-resource access. This is incredibly common in the OAuth world. 

The intent was for an RS-first flow, just like standard UMA. It could easily extend to an AS-first flow as Eve suggests, but that’s not the driving factor here at all. The client should have input into the process anyway, regardless of where it starts. I think there are a lot of not-fully-baked security considerations with an AS-first flow, though. More thinking in this area, and I would say it should be an extension of UMA and not in core if people really want that. 

So in the end, what we need (and what we’ve started to experiment with the MPD implementation) is a way to deterministically combine the scopes associated with various parts of the process. So we’ve got:

 - Scopes that the client is registered for (very common in the OAuth space, part of dynamic registration as well)
 - Scopes that the client asks for at the token endpoint
 - Scopes that the RS asks for when minting the permission ticket
 - Scopes that the RS registers for when registering the resource
 - Scopes that the RO’s policy allows in the presence of certain presented claims
 - Scopes that the RO might have added after the resource is registered (possibly for other resources?)

What we’re missing is a process that pulls these (and possibly others I’m missing) into a predictable and reliable combination process.

 — Justin

On May 19, 2016, at 12:09 PM, Eve Maler <eve@xmlgrrl.com> wrote:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-05-19

Minutes

Roll call

Quorum was reached.

Approve minutes

tbs

CIS prep

Don't forget about Cloud Identity Summit. It's not too late to register (contact Andi Hindle for assistance, wink wink). There's a Kantara Summit, an UMA talk, an UMA MasterClass, a HEART talk, and a privacy track, all relevant to what we do here. (And: BLOCKCHAIN!!!!)

Eve, Colin, Andi, George, Maciej, Sarah, Justin, and Ishan are all attending – and speaking. Nagesh may attend.

Meeting schedule

Let's put next week's meeting back on the calendar. Huzzah. We'll have a good long stretch of meetings through June and July.

Any huge absences? Please let Eve know.

IIW and EIC recaps

At IIW, beyond the "MPD" discussion:

  • Adrian convened a session where we discussed blockchain/smart contract implications for UMA. Think "escrow" where payment for access to a resource could be worked out, or proving certain elements of identity in a wide ecosystem.
  • Eve created a diagram describing different kinds of delegation: RO-to-AS (as an "agent" for executing to Alice's wishes), RO-to-RqP (delegating access to resources), and Resource Subject-to-Grantor (offline wrt the protocol, but an important business/legal relationship).
  • Adrian brought up ten kinds of "self-sovereign technology", different from self-sovereign identity". Think about a "personal" type of UMA authorization service. Contact Adrian for more information.

At EIC:

  • Eve gave a keynote that centered on UMA (and a HEART use case). Lots of discussion.
  • Ian gave a keynote where he called for an identity p
  • rofessional association; Kantara put up a pledge signup site!

Justin's change proposals

For reference: The wide ecosystem challenge analysis document. The challenges came from two sources: the identity protocols used to convey identity/claims require pre-established trust, and UMA itself requires a pre-established AAT. Justin's proposals eliminate the AAT (much as a very old version of UMA had only two tokens) and do a bunch of other cleanup, which tackles not only #wideeco but also #simplify.

We walked through the bullets in Justin's original email.

Changes include:

- Removal of the RPT endpoint, in favor of using the token endpoint and a new grant type (#153)
- Removal of the AAT (#154)
- Removal of extraneous bits of the resource set registration URL pattern (#155)
- Alignment of the discovery document with OIDC discovery (#157)
- Removal of “version” field in discovery document, instead document is published under new .well-known URL pattern (#159)
- Change use of “scopes” name in responses to something more explicit (#158)
- Ability of client to specify scopes in token request (#165)
- Addition of the claims-gathering URL to the need_info response, removal of “redirect_user” as redundant in this case (#167)
- Simplification of the “need_info” response structure, removal of extraneous object layers (#237)
- Rotation of ticket values on all requests to token endpoint or claims endpoint to mitigate session fixation and related attacks (#239, #205)

Discussion about "Ability of client to specify scopes in token request": In UMA V1.x, the flow is client-to-RS-first. The client is entirely "dumb" with respect to what scopes are available, and can only attempt access using one scope at a time, and the RS is entirely in control about how many scopes to register: one (stingy), or more than one (generous). Sarah suggests that Justin's motivation is privacy preservation: The client could essentially do a downscoping by requesting fewer scopes than the RS would have requested. But is this the motivation? Are both motivations relevant (downscoping and upscoping)? Also, does Justin's change enable an additional client-to-AS-first flow or is it still client-to-RS-first alone? If the client approaches the AS, how does the client indicate the specific RO and resource needed – does it need to know the rsid? On balance, might there be privacy-destructive aspects if Alice ends up sharing more access? Eve had pointed out at IIW that the asynchronous nature of the RO's control means that the client shouldn't really get to say what scopes it requests anyway. George thinks it's more of a negotiation. And maybe negotiation among RS, C, and RO isn't entirely bad? To be discussed on the legal subgroup call. (smile)

It will be key to have accurate swimlanes and hopefully some spec text to stare at during next week's call.

Attendees

As of 15 Apr 2016, quorum is 7 of 12. (François, Domenico, Kathleen, Sal, Nagesh, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah)

  1. Domenico
  2. Kathleen
  3. Nagesh - Accenture and JPMorgan Chase experience in IAM - now at Optiv and working at home with schedule flexibility!
  4. Andi
  5. Robert
  6. Eve
  7. Sarah

Non-voting participants:

  • Adrian
  • John W
  • Jin
  • Ishan
  • George
  • Colin
  • Scott

Regrets:

  • Sal
  • Mike

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma