[WG-UMA] Notes from 26 Jan 2011 ad hoc telecon on scoped access
Eve Maler
One issue for today is: Why should the AM have to "go to the host" (make requests of other parties)? This happens when the AM has to go retrieve information about actions (not necessarily lodged at the host, but this info has to be publicly accessible). It's a decision we made and spec'd several weeks ago, but there are lingering concerns.
Paul has concerns about:
1. Access control discomfort around the host having to make the action information publicly accessible
2. Inefficiencies around the host having to register URLs for actions when it could register the data itself
3. Dependency issues around the AM having to retrieve something rather than having the info provided to it automatically
The counter-arguments would be:
1. Action information is part of required "OAuth SP" API documentation and is ideally broad-based and even standardizable, not per-user.
2. There are inefficiencies in having the host have to register the identical information at multiple AMs. (If the host provided the information by value vs. by reference, it would have to do it per AM, but each of the host's users at the AM could inherit this information.)
3. The current rreg spec text does try to handle the dependency issue by saying when the AM has to retrieve action data and by leaning on HTTP caching abilities for limiting pointless requests by the AM.
Registering action information by value/push does add complexity to the host (and we have a design principle to push complexity to the AM vs. hosts and requesters), but at the margin it's not very much more complexity because the host already has to maintain state about which resource sets have which actions, and it knows exactly when the action landscape changes.
Maciej is concerned about changing up the specification too much in too short a timeframe; his team has already implemented the new actions-by-reference design and would like to get feedback on the existing design before changing again. Eve would like to get "ready for prime time" as soon as possible in sharing the whole scoped-access design (which is not done yet) with the wider community, e.g. the people working on JWT and OAuth2. We agreed to keep the action description registration process the same for now, and seek public comment as we go.
The second main issue for today has to do with the exchange of information around scoped access. In fact, Maciej's team had previously invented a means of doing "bilateral OAuth", where the AM has to access a protected endpoint at the host to POST scope information there! But this sounds too complicated. We want to keep the protected communication pattern going in one direction (host makes protected calls at the AM; the AM never has to make protected calls at the host).
Paul is in favor of using emerging JWT tools to achieve efficient entity authentication (such as the host passing this requester along to the AM in a "solution 2: requester as dumb mule" way in Step 2) without requiring lots of back-channel calls in real time. He is talking to Sal later today about this. Paul prefers public key for this; Eve notes that we talked previously about "prearranged key infrastructure" and this is the main requirement (vs. public key per se, though it's a good thing for those who can handle it). Since the AM and host already have a back channel established, there are plenty of opportunities -- such as during Step-1 introduction -- for them to do something like an association handle trick and even to do stronger entity authentication through things like signed metadata.
Paul is not in favor of using JWT to pass around authorization information (vs. authentication information). He's talked in the past about PKI as the "biometrics of the web". His vision requires cleanly separating token-based authentication of an entity from the authorizations (scopes) it has won. So a requester has a token that works at the AM for identifying/authenticating itself, but its scopes are recorded in a resource stored at the AM.
Since UMA allows ad hoc discovery of an OAuth authorization server, it allows the AM and host to "float" and not have to be in the same administrative domain (or, equivalently, have this relationship be managed entirely out of band). Paul's contention is that OAuth can't help us with our specific use cases around scope, so we'd have to invent a scope/authorization mechanism on top of OAuth without using its scope features. In essence, we would use OAuth and JWT only for authentication in Step 2 -- and this is what Paul and Sal will work on today.
When it comes to Step 3, Paul recommends going to a strict PDP/PEP model, which would require the host to make a real-time call to validate tokens at all times. He anticipates that any other way of handling scope (that would package up the necessary information for the requester access token in a JWT) would require one token per action per resource set, which seems untenable. We're extremely keen to explore this next step fully as soon as possible.
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma