...
- 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)