UMA telecon 2016-07-14

Date and Time

Thursdays, 9-10am PT
- Skype: +99051000000481 / US +1-805-309-2350 / international lines / web calling interface / code 1782540
- Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2016-06-30, 2016-07-07
For reference: MPD sequence diagram and generic low-level sequence diagram
- Trust elevation extension mechanisms and MPD
Registering multiple resource sets
- Input from George on existing spec text?
Client awareness of scopes
- Concrete proposals based on multiple-resource-set directions?
AOB

Minutes

Roll call

Quorum was not reached.

But we had great "critical mass" for rough consensus...

Approve minutes

Approve minutes of UMA telecon 2016-06-30, 2016-07-07: deferred.

MPD

A lot of the simplifying decisions in MPD have come from IoT. Some work Eve is involved in is IoT use cases. Consumer IoT devices influence RS and client scenarios quite a bit in health, e.g. More to come on that, no doubt.

Trust elevation: We've discussed a variety of scenarios in the past where the trust elevation mechanism might be extended to account for others' needs. We want to be sure to still be capable of that. MPD thinking: The claims/interaction endpoint is becoming a be all/end all interaction endpoint, and should be used for all interaction (is the theory). What was an (UMA) RPT endpoint that accepted JSON is now, in MPD, the OAuth token endpoint that accepts forms with key value pairs. Indeed, the UMA inputs were simple strings. The scenarios for extension included things like:

Smart contracts that the (UMA) client/RqP is bound by
The environment exhibited by the client/RqP that the AS can detect
- For contextual types of step-up authentication for complex auth loops or chains?

It could be that working within the simple structure of key/value pairs of forms is fine. We can write it up and ask for feedback.

Naming questions ("phrasing!"): Let's understand all the naming opportunities/issues first, then name them in concert later. Some challenges:

resource set, protected resource, resource...
client, Client, UMA client, OAuth client...
relying party, requesting party, resource server, client...
(newer) UMA refresh token, (who know what else?) consent token, something else...
registering permissions, registering a ticket, registering resource set(s) for getting a ticket...

Registering multiple resource sets (while getting a permission ticket): Justin prefers the common case of registering a single resource set. Mike plays devil's advocate; in LDAP, you have multi-valued things, so he assumes arrays anyway. Otherwise the AS has to check whether the thing he's getting is single-valued or not. (The ghost of) Nagesh prefers all arrays. Do we need more inputs on this? Mike thinks it doesn't make or break either way. Justin thinks there's a different syntactical approach we could take vs. arrays entirely.

Kathleen had been discussing consent structures in RDF-OWL, which could be associated with resource sets. Even if we don't go this far, because it could trip up AS interop, could it be an extensibility point? Actually, our discussion on June 23 might have been in the wrong direction because we're actually talking about registering resource sets and scopes in the context of getting a permission ticket – not original RSR.

Those who have an alternative to propose vs. this one should send it to the list for consideration by next week.

Regrets for next week: Andi, Domenico.

Regrets for the following week: Andi, Justin.

Attendees

As of 14 Jul 2016 (pre-meeting), quorum is 7 of 12. (Domenico, Kathleen, Sal, Nagesh, Andi, Robert, Paul, Agus, Maciej, Eve, Mike, Sarah)

Domenico
Sal
Andi
Eve
Mike
Sarah

Non-voting participants:

James
Justin
François
Scott
Arlene

Regrets:

Maciej
John

Browser not supported