https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-13 MinutesRoll call Quorum was not reached. Approve minutes - Approve minutes of UMA telecon 2020-07-09 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-09 , 2020-07-16 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-16 , 2020-07-23, https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-23 2020-07-30, https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-07-30 2020-08-06 https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2020-08-06 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 George Fletcher https://kantarainitiative.org/confluence/display/~openid@gffletch.openid.aol... – any opinion? Relationship Manager profile Alec's latest spec text is in this thread https://groups.google.com/g/kantara-initiative-uma-wg/c/vcB9S3mksn8. 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 *Eve Maler*Cell or Signal +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl