UMA telecon 2018-10-18

Date and Time

Thursdays 9am PT – special time this week 9:30-10:30am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/857787301
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2018-09-20, UMA telecon 2018-10-04, UMA telecon 2018-10-11
Prabath demo of new WSO2 implementation of UMA2
180 degrees use case / decoupled use case discussion
Update on PIPC
Continue on Adrian's notification use cases
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2018-09-20, UMA telecon 2018-10-04, UMA telecon 2018-10-11: APPROVED.

Prabath demo of new WSO2 implementation of UMA2

(View the recording of this meeting from this point onward.)

WSO2 Identity Server 5.7.0 was released last week. They had implemented UMA1 but that didn't really take off. They have implemented dynamic client registration, the resource registration API/endpoint, the permission endpoint, the token introspection endpoint, the token endpoint, and resource access policies implemented in XACML (internal to the engine).

On the roadmap for 5.9.0 (Q1/Q2) is interactive claims gathering, SAML as a claim token (just ID token now), the UMA metadata endpoint, updates to the user portal to give an end-user UI (right now their customers build their own UI; the updates would include end-user analytics for resource access by RqPs), notifications on approved RPTs, and integration with the WSO2 API Manager RS gateway.

The demo use case involves Kaiser as an RS, a Medicare client app, Tom as an RO, and John as an RqP. John logs in using OIDC.

Some feedback from WSO2: Steps 7-9 in blue (the C-to-RS-first and permission ticket) are considered onerous. Keycloak also did something similar in an extension of theirs, though in their case it seemed the motivation was more about colocated AS/RS/RO (an "enterprise RO"). WSO2 anticipates this would be the most common case, but they're planning for other cases like patient/doctor, where they would typically have multiple Identity Servers in the control plane in multiple trust domains.

AI: Prabath: Document the service-to-service use cases where C-to-AS-first UMA would make sense.

E.g., a Kubernetes environment, potentially microservices chaining, etc.

Schedule change-up

In addition to not meeting next week due to IIW, let's move our next meeting from Thu Nov 1 to Fri Nov 2, same bat time. We will discuss the C-to-AS-first pattern. We will try and get an Identos demo of sorts, and a discussion of all the "C-to-AS-first" solutions/extensions out there, along with use cases for the solution.

AI: Eve: Change the calendar and try to get Pedro to join the call as well.

180 degrees use case / decoupled use case discussion

Nancy has written up some "180 degrees" use cases, which she'll share more widely soon. These got Eve thinking.

We briefly discussed use cases where the requesting party needs to trust the resource owner before taking some action (potentially against resources shared), e.g. a loan officer needing to trust that the putative resource owner is who they say they are so that the (e.g.) personal attributes (resource) shared can be trusted to be associated with that resource owner "bearer". This way, the loan officer can approve a loan (which might be a second resource that the same resource owner could later share with others).

The current UMA model allows the RO and their AS to match RqP claims (not just a plain authenticated identity) against policy, and the RO can be decoupled (asynchronous) from that process. The client that the RqP uses is explicitly accounted for in the protocol, and UMA has a framework for this matching and for the RO's delegation / access granting to the RqP. But it only accounts for the client that the RO uses to interact with the RS and AS through the OAuth authorization endpoint (resulting in a PAT), and otherwise the client handling on the RO side is implicit.

The notion of the RqP needing to trust the RO and the RO needing to grant resource access to the RqP seems similar to the "decoupled" use cases, where a CSR or bank teller needs to know that Alice is really Alice before getting access to her account.

What would make sense for ensuring that the RqP could come to trust the RO "binding"? Alec will describe some work they've done along these lines in our next meeting.

Update on PIPC

Deferred.

Continue on Adrian's notification use cases

Notification came up in WSO2's work, which may be relevant to both Adrian's use cases and the needs for notification/polling seen in the decoupled use cases. To be pursued more shortly.

Attendees

As of 18 Oct 2018, quorum is 5 of 8. (Domenico, Peter, Sal, Andi, Maciej, Eve, Mike, Cigdem)

Domenico
Peter
Sal
Andi
Maciej
Eve

Non-voting participants:

Alec - Identos - Using UMA a lot to solve patient-facing services; read the spec many times – has many pilots going in Canada and responding to lots of RFPs, including Ministry of Government Services - within six months will have a public version
Bjorn
Prabath
David
Dewni
Tim

Regrets:

Mike

Browser not supported