UMA telecon 2012-02-16

Owned by Former user (Deleted)
Last updated: Feb 16, 2012Version comment
3 min read

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" (smile), 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.

  1. Mohammad, Alam
  2. Catalano, Domenico
  3. D'Agostino, Salvatore
  4. Hardjono, Thomas
  5. Machulak, Maciej
  6. Maler, Eve
  7. Moren, Lukasz
  8. Szpot, Jacek

Non-voting participants:

  • Cox, Kevin
  • Nederkoorn, Cordny

Regrets:

  • Miles, Arnie