UMA telecon 2012-02-16

Date and Time

WG telecon on Thursday, 16 Feb 2012, at 9am PT (time chart)
- Skype: +99051000000481
- US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

Roll call
Approve minutes of 2012-02-09 meeting
Interop planning and implementation discussion
Review open action items
KI.org UMA blog post planning: nutshell? interop? open source?...
Work through issues
- Is client_credentials the right grant-type choice for multiple requester tokens? (email)
- JSONified config data okay? (edits from last week)
- Conformance flag around policy handling? (Gerry B discussion)
- 31 (baskets)
- 41 (JSON media types)
- 7 (caching language)
- ...
AOB

Minutes

New AI summary

Action item number	Assigned To	Status	Description	Comments
2011-09-22-4	Various	Ongoing	Build list of FAQs on the wiki.	Paul to write a FAQ on "access granularity". Susan to draft a FAQ on "government PDS use cases". Dom to translate entries into Italian. Eve to link to Cordny's UMA article in Dutch from FAQ.
2011-09-29-1	Frank, Sal, Dom, Sus, Kevin et al.	Open	Prepare Trust Model "user guide".	In progress. Let's try and prepare something lightweight for the interop wiki.
2012-02-16-1	Dom, Eve, Maciej	Open	Work on interop wiki area and early-March blog post.

Roll call

Quorum was reached.

Approve minutes of 2012-02-09 meeting

Minutes of 2012-02-09 meeting APPROVED.

Interop planning and implementation discussion

Domenico, Maciej, and Eve will follow up on interop wiki content. Eve will send mail to the list with her starter thoughts.

Review open action items

Domenico agrees to start translating the first FAQ or two into Italian.

KI.org UMA blog post planning: nutshell? interop? open source?...

Let's target early March for a post advertising the interop.

Work through issues

49 (client_credentials)

What are implementations doing today? If Alice and Bob both use CopMonkey for protecting resources, how does a single requester get a unique token at CopMonkey for each authorizing user? Currently, the SMART implementation isn't using the client_credentials flow for requesters getting tokens; it's using the authorization_code flow, so that the tokens it gets are, at a minimum, unique to the requesting party/requester/AM. But it's not unique to the host, nor to the authorizing user (unless the authorizing user and requesting party are the same). So, at a minimum, our requirement to use the client_credentials flow isn't helpful.

Our original reason for using client_credentials was that, to remain purely claims-based, the permission process shouldn't depend on anything that isn't ensconced in a permission data structure. However, using authorization_code doesn't necessarily harm this goal, if it's just being used to disambiguate the requesting party.

SMART does token upgrades now, the way the spec calls for, but this isn't a viable solution for a proper secure ecosystem. In particular, the token is applicable to multiple hosts, and being a bearer token, this is dangerous. If we were to use signed tokens, this could be solved readily, but Eve would very much like to have a bearer token option available.

In fact, the AM, having had a host register a permission on behalf of an authorizing user-requester combination, is in possession of the specific host and authorization user in question by the time the requester shows up to ask to get that permission. Can the AM get just a bit smarter, and manage the token upgrade vs. new token process entirely on its own? We're thinking maybe yes. Does it need to information the requester which one it has done, so that the requester can manage its own token state sufficiently? Perhaps so. This seems like a bit of a hack, however.

Note that we had "defined away" the problem of which user's stuff the requester is attempting access to. If the API at the host doesn't obviously distinguish between users, the requester is assumed to make the API call in such a way as to distinguish them. Does this help at all?

The token is opaque, so the AM could do really whatever it wants. Could the AM manage the situation by segregating host-specific and user-specific information by putting encrypted information in (or associating it with) a single humongous token? This would be "Jacek's expedient workaround" , where we tell the AM not to release token status information to hosts to which the information doesn't belong.

41 (JSON media types)

This should be pretty easy to do. Thomas will do this when he has the time.

Next Meetings

WG telecon on Thursday, 23 Feb 2012, at 9am PT (time chart)

Attendees

As of 14 Feb 2012, quorum is 7 of 12.

Mohammad, Alam
Catalano, Domenico
D'Agostino, Salvatore
Hardjono, Thomas
Machulak, Maciej
Maler, Eve
Moren, Lukasz
Szpot, Jacek

Non-voting participants:

Cox, Kevin
Nederkoorn, Cordny

Regrets:

Miles, Arnie

Browser not supported