As of 6 Jan 2011 (pre-meeting), quorum is 8 of 15
Non-Voting:
Guest:
Apologies:
Quorum was reached.
Minutes have not yet been approved. Approval postponed to next conference call.
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 regarding scope-related issues - in particular, with reference to the:
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.
Solution 2: "Requester as dumb mule"
Host gives encrypted information to requester, to convey to the AM.
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.
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.