UMA telecon 2019-10-
...
03
Date and Time
- Thursdays 6am PT
- Screenshare and dial-in: https://global.gotomeeting.com/join/857787301
- See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar
Agenda
- Roll call
- Approve minutes of UMA telecon 2019-09-19
- XYZ use cases
- Nominations for chair and vice-chair
- AOB
Minutes
Roll call
Quorum was not? reached.
Approve minutes
- Approve minutes of UMA telecon 2019-09-19
tbs
XYZ use cases
tbs
Nominations for chair and vice-chair
...
MOTION:
- Minutes of UMA telecon 2019-09-19 APPROVED.
XYZ use cases
Eve suggests that, for at least the use cases that UMA doesn't cover today, we should be putting them in our GitHub issues. We can tag them with "extension" and "XYZ", and this allows lookup for anyone who might be interested to create an UMA extension, as well as for anyone interested to see UMA-related use cases that have arisen in the XYZ context and applicable to the universe. As well, if someone is solving such a use case in some other manner, through (say) profiling existing technologies (Sal mentioned signed claims with an expiration date and AS signatures for the offline RS use case, along with a smarter client), those could be explored too. So GitHub recording gives us an "all of the above" strategy for solving use cases.
Discussing that use case: Cigdem discovered that the ace-actors draft had gotten archived. The "client AS" (CAS) concept was only in that draft. We had thought that this document was key in the thinking of the ACE group (e.g. to recognize "requesting parties"), but they've now backed off of all of that. Sal will help with more offline/IoT use cases. In UMA2 we achieved more IoT friendliness, mainly through explicitly allowing local RS validation of a self-contained RPT (access token) vs. strongly requiring token introspection as in UMA1.
Discussing the Alice-to-Alice use case: Eve and Justin have had further discussion about whether UMA's method of using the UMA claims collection methods (whether pushing or interaction) for both Alice-to-Alice sharing and Alice-to-Bob sharing is appropriate. Her thinking is that using UMA's method in all cases is appropriate because the RqP's identity isn't known until you collect the claims, and in fact, it's not really an identity at all, it's "some claims" that satisfy policy (or don't). In the Pensions Dashboard use case, it's "little Alice" (lower assurance) using a special account aggregation client vs. the "big Alice" that is highly assured on the resource owner side. And in the case of HEART-style use cases like "btg" (break the glass), it's a lot more like role-based access based on claims sought in policy/supplied. Finally, we found usage of the OAuth authorization endpoint troublesome when used on the requesting side for the AAT because it required early and strong identity-based binding of Bob to the AS, and we could see this getting in our way when use on the owner side if we were to do more work around the Alice-to-AS relationship in future for getting visibility into Alice's assurance level (currently the "AS app" is outside UMA's scope). All this is to say that UMA had its reasons for aligning on its own mechanism for treating all requesting parties alike, and we expect that surely XYZ will too.
Peter will attend to his use case on his return.
Nominations for chair and vice-chair
MOTION: Sal moves and Thomas seconds: Nominate Eve for UMA WG chair and Maciej for WG vice-chair for a new annual term.
Motion PASSES by ACCLAMATION.
MOTION: Andi moves and Sal seconds: To formally thank our chairs for their service and exemplary leadership on an ongoing basis. 
Motion PASSES by ACCLAMATION. (Eve says thanks!)
Attendees
As of 16 Jul 2019, quorum is 5 of 9. (Domenico, Peter, Sal, Thomas, Andi, Maciej, Eve, Mike, Cigdem)
...
- Domenico
- Sal
- Thomas
- Andi
- Eve
- Cigdem
Non-voting participants:
- tbsNancy
Regrets:
- tbsMaciej
- Peter