UMA telecon 2011-01-20

Date and Time

WG telecon on Thursday, 20 Jan 2011, at 9-10:30am PT (time chart) – regrets from Eve; Maciej M. will chair
- Skype line "C": +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214

Agenda

Assign note-taker for the day
Roll call
Approve minutes of 2011-01-13 meeting
Action item review
Scope issues (report from last week)
- Discuss further issues related to invisibility of resource set info to requester
- Have requester get new token for every resource at same host/user? Have requester upgrade the same token over and over? Other?
- Assign AIs for core/scoped-access/rreg spec edits
Further discussion of tclaims and OpenID Connect influence on them?
AOB

Attendees

As of 6 Jan 2011 (pre-meeting), quorum is 8 of 15

Mohammed Alam
Trent Adams
Paul Battersby
Paul Bryan
Domenico Catalano
Sal D'Agostino
George Fletcher
Thomas Hardjono
Maciej Machulak
Maciej Wolniak

Non-Voting:

Kevin Cox

Guest:

Greg Turner

Apologies:

Eve Maler
Lukasz Moren
Susan Morrow

Minutes

Roll call

Quorum was reached.

Approve minutes of 2011-01-06 meeting

Minutes have not yet been approved. Approval postponed to next conference call.

Action item review

2010-11-18-4 Eve Open Capture new user stories in the wiki. In progress. Lots of edits made; more to come.
2011-01-06-1 Paul Bryan, Sal Open Come up with a recommendation for using or fixing JWT to solve the requester authentication/correlation problem in Step 3.
2011-01-06-4 Susan Open Write draft UMA trust model. Under way, with Rainer and Paul Battersby. Has a partial dependency on 2010-11-18-4.

Discussion

Discussion regarding scope-related issues - in particular, with reference to the:

ad hoc scope call 12 Jan 2011
last week’s conference call

There are 3 things that need to be discussed further, which are related to invisibility of resource set info to requester. Earlier calls proposed three solutions:

Solution 1: "Requester as smart mule"
Host gives information to requester in the clear, to convey to the AM.

Pro: Little crypto, no extra web service calls.
Con: Exposes data the requester has no right to.

Solution 2: "Requester as dumb mule"
Host gives encrypted information to requester, to convey to the AM.

Pro: No extra web service calls.
Con: Requires host/AM "prearranged key infrastructure" to manage this trust

Solution 3: "Referral resource and artifact"
Host creates a referral resource at the AM on a back channel, and gives the requester only a pointer to it.

Pro: Secure, allows referral to have lots of useful info in it.
Con: Requires extra web service calls, requires more endpoints and sub-protocols.

The back channel between the Host and the AM has performance issues. This should be included in the specification - i.e. that there are “known performance issues”. If the AM gets hundreds of thousands of requests from the requester then it may need to go to the AM with every such request - then the AM may stop responding to the Host if it decides to.

DDoS-type attacks can be stopped without a problem (not accepting requests from Hosts) but the problem is more severe for legitimate requests that come from Hosts.

We discuss how the requester knows which token to use if it wants to access a resource? Requester has to know what the resource is and what the group is for every single resource the requester has to get a token. PAP/PDP/PEP model - the token is only used to authenticate the requester.

We should decide whether the token should be used for authorization or for authentication only.

In the classic model, the host and the AM need to be more tightly integrated, sharing occurs between the two. Host has to have a back channel to the AM - for registering resource groups, etc. Uses this channel for requesting authorization from the AM as well.
The requester may act as an intermediary for transmitting the authorization.

The specification might be pushed towards the PDP model - the token is mostly for authenticating and not authorizing requests. UMA use cases are different than OAuth use cases - you cannot take a token from AOL and go with this token to Yahoo. Scopes are not bound to resources.

We should look at JSON tokens and JWT.

What should be the granularity of tokens and resources. Are we OK with one token per resource? It’s better to have different one. One token per resource group.

We’ve decided to possibly schedule an ad hoc call regarding the protocol next week to discuss resource registration and scoped access.

Domenico discusses the newly sent Trusted Claims document and mockups.

Next Meetings

WG telecon on Thursday, 27 Jan 2011, at 9-10:30am PT (time chart)

Browser not supported