UMA telecon 2020-08-27

Date and Time

Alternate-week Thursdays 10am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/485071053
- United States: +1 (224) 501-3316, Access Code: 485-071-053
- See UMA calendar for additional details: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23, 2020-07-30, 2020-08-06, 2020-08-13, 2020-08-20
PKCE and UMA wrapup
Relationship Manager profile
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2020-07-09, 2020-07-16, 2020-07-23, 2020-07-30, 2020-08-06, 2020-08-13, 2020-08-20

Deferred.

Sustainable Self-Sovereign Agents (S3A)

There was a meeting held earlier today – notes and a recording here. For more info or to get involved, contact Adrian. UMA is being put in play.

PKCE and UMA wrapup

Any final quick comment on this? Alec has suggested some updates to his latest wording in this email thread, though he's not perfectly happy with it. Eve suggests putting it in the UIG anyway, and drawing people's attention to the (non-normative) wording for use and comment.

Adrian notes that a UserInfo endpoint, interacted with in a fashion that is sort of variable in the SSI context (e.g. the first contact could be a QR code), could be an interactive claims gathering endpoint. We have also in the past discussed how we need notification functionality, which requires out-of-band endpoints.

Relationship Manager profile

Alec sent thoughts on the policy manager API in this email thread.

Let's see if we can capture a deeper "why"/comparison statement that could go into the profile. (See the openings of the UMA2 specs for an example.) Alec's new wording does contain this sort of why/comparison/motivation. In other words, in the case where the AS is a "multi-user" AS and Alice (the RO) has no choice about which one it is that she has to use, we want to make sure to preserve as much of Alice's agency (control) in the situation as possible. So pushing policy management out of the AS and into a client app gives Alice this point of control. She wants some freedom to independently verify who is providing advice about what policies to choose. We have, in the past, discussed AI engines that implement things like relationship-based policy. This client could provide such functionality.

The token that protects this policy management interface is different from the PAT but is similar to it. Let's call it a "PMT" right now, for argument's sake.

The FPX work that is being dropped here is the policy manager's interaction with the RS. The previous discussions we were having about "cascading" AS's had to do with the situation when the server-side (multi-user) AS might hold some policy and the client-side (Alice-specific) relationship manager/policy manager might hold some policy too, and then you have to figure out policy ordering. But Alec has left that out for the sake of simplicity.

Adrian objects to working on this profile because it optimizes for a situation where the server-side AS isn't Alice's fiduciary. Alec believes there is nothing in the profile that precludes the RS from presenting 10 AS's and letting the RO choose. Eve believes that Tim has previously concluded that any server-side AS that serves multiple users would have a hard time being anything more than a limited fiduciary (but we have to check). As well, a key requirement expressed by a number of healthcare players has been to "federate" policy management across multiple servers, so this seems to be consistent in a certain sense. Her past discussions with Nancy revolved around "consent management servers" (CMS's) and she brainstormed a "consent access token" (CAT?) to protect a "consent API".

Domenico notes that PSD2 has the concept of a collector – an aggregator of data from multiple bank institutions. This is what this "RO client" (can we call it that? Thomas suggests it) enables the RO to do with policies, across any number of AS's, whether the RO chose them or not.

Scott has been context-switching every time he hears "client", thinking it means our classic "UMA client" that the RqP uses, so we should also qualify "client" when we mean the one that the RO uses.

Should we go back to the RO-client interfacing with both AS's and RS's? Let's think about that.

Adrian loves the notion that the market wants some kind of policy management wallet or agent. Is this bidirectional? Is it a read/write API? He suggests extending the "Adrian clause" to the AS as well the RS. Let us ponder that.

Eve adds on top: We may want to think about another modular profile that we should consider drafting, a "prove to Bob that Alice is who she says she is" profile, now that we'll have an RO-client that incidentally allows for Alice-authentication. This would help us solve for CIBA-like use cases (which we've discussed ad nauseam before).

Attendees

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

Michael
Domenico
Peter
Sal
Thomas
Eve

Non-voting participants:

Alec
George
Adrian
Alex
Scott
Anik

Regrets:

Tim

Browser not supported