Quorum was reached.
Approve minutes of UMA telecon 2018-06-14, 2018-07-12: APPROVED by acclamation.
Deferred.
We have been hearing that WSO2 has been planning an UMA2 implementation this quarter; Eve will check in with Prabath.
Eve has updated the Implementations page's Keycloak entry to supply Pedro's provided information. It appears that there is an extension to the permission endpoint to all the RS to push claims to that endpoint. "When creating tickets you can also push arbitrary claims and associate these claims with the ticket ... (example shown) ... Where these claims will be available to your policies when evaluating permissions for the resource and scope(s) associated with the permission ticket.". Is is something that would be interesting to standardize for interop? We can ask Pedro in email. He had proposed an extension (see issue 355) that would shortcut using a permission ticket at all, for narrow-ecosystem enterprise purposes.
Mike is meeting with Pedro tomorrow to discuss interop testing. Mike's demo at Identiverse can be turned toward such purposes, with Keycloak as the AS. It looks like both Keycloak and ForgeRock implement just claims pushing for their claims collection flows at this point. Gluu's OXD server has a kind of UMA client middleware capability, and it would be happy with either type of claims collection. The typical assumption in pushed-claims flows these days is that Alice's AS is her IdP and also Bob's IdP, but ID token validation should properly still be "full validation", with no shortcuts.
In this kind of ecosystem, obviously the AS can include itself as an additional audience alongside the client as the first audience because it knows ahead of time that it will be the one ultimately consuming it. In any "wider ecosystems" than this, that is, IdPs for Bob that aren't Alice's AS, tokens that get pushed by back-channel means can't be very dynamic about their audience predictions.
An insight about UMA's grant structure and main options, based on the fact that a permission ticket provides a framework for allowing a variety of looping patterns of state-preserving client-to-AS-token-endpoint interaction:
In Eve's discussion with Bertrand Carlier for his (forthcoming?) blog post, he had the insight about the authorization code flow, pointing out the analogy of the permission ticket to a "mutable authorization code" (along with noting that the PCT is very like a refresh token and the RPT is like – is! – an access token). It has been asked why we have a claims interaction endpoint, and didn't reuse the actual authorization endpoint. Mike does refer to the claims interaction endpoint as our "authorization endpoint", which is helpful rhetorically. Although it might take forensic analysis of our archives , we might never have formally considered reusing the authorization endpoint directly vs. the claims interaction endpoint (former name in UMA1: requesting party claims endpoint). Our main design effort for UMA2 was inspired by the exploration in MPD (see here, for example). However, note that customization would have been required anyway, and the semantics of the UMA version cover gathering of claims beyond just verification of a unique identity.
Identiverse talks that touched on UMA:
One tidbit: Eve remotely attended the first OAuth WG session during the Montreal IETF 102 meeting. During this session, Justin mentioned UMA, CIBA, and the Device flow as exemplars of applying a permission ticket paradigm that could help the group develop an actual model of what a grant flow is.
We should think about how we can ensure that UMA and the use cases it solves can influence the conversations going on in the OAuth and OIDC communities, and be influenced as appropriate. For example, the distributed OAuth work has parts that bear some similarity to UMA's AS discovery mechanism. It appears the CIBA spec is going to be broken up into a core and a sector-specific spec. Mike took notes on his action item to create an "UMA for decoupled/UMA-protected backchannel endpoint" swimlane. George in chat: Completely agree with engaging with IETF on the new suggestions and overlaps with UMA.
Deferred.
As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)
Non-voting participants:
Regrets: