UMA telecon 2020-08-13

Owned by Eve Maler
Last updated: Aug 20, 2020

UMA telecon 2020-08-13

Date and Time

Agenda

Minutes

Roll call

Quorum was not reached.

Approve minutes

Deferred.

PKCE and UMA

Do we, in fact, have to say anything about repeated ICG cycles. You get a refreshed ticket from the redirect cycle, and don't have to "pass go" (go through the token endpoint) when you do that. If a token call is made, then we're good because there's a natural mitigation. If not, then we probably need to do more analysis. Calling Former user (Deleted) – any opinion?

Relationship Manager profile

Alec's latest spec text is in this thread.

A Relationship Manager (RM) should be able to interact with multiple AS's. Policy setting interactions with an app and RqP-type interactions at an app should be able to be totally separated.

In the UMA1 world, we had a notion of OAuth-protected APIs that were standardized by UMA, called the "Protection API" and the "authorization API" (only the former survived in UMA2). As a result, the "UMA AS" (noting that we have based UMA concepts on OAuth, in a very real and important sense – borrowing token handling and such) had to play the putative role of an "OAuth AS and RS" because it has the job of presenting these OAuth-protected APIs. It's a little bit like turtles all the way down.

Somewhat similarly, we now have the situation that an individual may want to use an app that allows for policy setting to protect their resources (control API or protect API – but watch out for naming because we already have a "protection API" in UMA2 FedAuthz that governs the AS-RS interface), and an individual may want to use an app that allows for managing their claims (manage API), and we now want to standardize these APIs in order for an AS to interact with a client application to do each of these functions interoperably. If the same app is used by the same individual such that they set policy at an AS to protect their claims (for use by that same AS or a different AS in the course of satisfying UMA policy), then that individual is an RqP (as well as being an RO by definition because we're on the "phase 1" side of UMA) and that single app is a Relationship Manager by virtue of the colocation of the two APIs in one app.

Thomas notes that in this scenario, the API is a "resources-control" API because it is, in practice, controlling resources, and a "claims-manage" API because it is, in practice, managing claims as the specific resources.

Is it sufficient, in that case, to simply say that if the manage API is UMA-protected and control-API standardized, then RO=RqP? It's more like the client (or user agent) is "cascading" in this scenario, because it calls both the manage API and control/protect API.

Big question: Is it possible for the two APIs to be specified entirely separately, because they could be called separately?

Maybe – or maybe not, since the "wallet" concept and individual control were at the heart of the original proposal. Sal says: I think RO_RQPT is at the crux, and to solve the Notice and Consent "Problem" is that the RO_RQPT needs to be in possession of policy and that consent is agreed not forced down. Thomas adds: The RM is the point at which to set consent rules.

Attendees

As of July 8, 2020, quorum is 6 of 10. (Michael, Domenico, Peter, Sal, Gaurav, Thomas, Andi, Maciej, Eve, Mike)

  1. Michael
  2. Peter
  3. Sal
  4. Thomas
  5. Eve

Non-voting participants:

  • Scott
  • Alec
  • Adrian
  • Patrick
  • Bjorn
  • Nancy