In 'classic' OAuth, a user:
1) facilitates a Consumer and Service Provider establishing keying material in the context of him/herself so that the Consumer can subsequently use those keys when requesting from the SP the user's attributes
2) can define permissions at the SP specific to the Consumer (i.e. read not write etc) - these access rules stored at the SP against the keys of 1)
From the 'access control management' PoV, the above model has the user making lots of access control management decisions - one each time a given Consumer wants identity from a given SP. What's more, subsequent management of all those decisions will be tough because the rules are spread out all over the place (at all the various SPs).
ProtectServe keeps the data distributed, but centralizes the access control management. Rather than directly collecting, storing, and managing a user's access control decisions for the attributes it stores, an SP will abdicate these duties to what Eve calls a 'Relationship Manager'. The Relationship Manager itself holds no identity attributes, only permission sets for identity attributes stored elsewhere (at the user's SPs).
User's create, manage (and hopefully can reuse) access rules at the Relationship Manager, rather than at the various and disparate SPs.
The implication is that, if and when an SP gets a request for a user's identity attributes from some Consumer, the SP, rather than looking at some locally stored access rule, instead queries the user's Relationship Manager for the decision (this query seemingly protected by Oauth as for any other identity query). Upon receipt of such a query, the Relationship Manager would
a) check to see if the SP (acting as an OAuth Consumer) was 'OK', i.e. that the User had introduced the two
b) check to see if the original request from the original Consumer to the SP should be approved based on the rules the User had defined
c) return the results of b) to the SP
Some thoughts
1) Because the Relationship Manager gets lots of queries of the sort
'Consumer1 is trying to access Alice's calendar at SP3'
the RM would be able to get quite the glimpse into Alice's online activities. Some creative crypto might help
2) Eve didn't describe the mechanism by which Alice, when visiting 3rd National Visa (an OAuth Consumer) would get over to CopMonkey (her RM) to specify permissions for Visa accessing her calendar at schedewl. Perhaps something like
i) Alice helps OAuth between Visa and Schedewl
ii) Schedewl responds back with a 'Talk to CopMonkey'
iii) Alice helps with Oauth between Visa and Copmonkey
iv) CopMonkey records the access rule for Visa accessing schedewl
v) later, when Visa asks schedwel for Alice's calendar, schedewl knows to ask CopMonkey before granting
3) Most powerful would be for the Relationship Manager to also track (or be able to access) the user's social relationships - thereby allowing Alice to define rules like
Visa can access my work calendar at schedewl if doing so on behalf of my Boss, but can also access my personal calendar if doing so on behalf of my sisters.
4) The Liberty Alliance has recently been collecting use cases around the idea of a 'Citizen Dashboard', the hypothetical place where a citizen could go and see (amongst other things) a record of all the queries for their identity made from one government department to another - and the results of those queries. Such an application would be a key piece of a Relationship Manager.
Liberty has also toyed for some time with the idea of defining protocols in support of such a centralized policy point - but never did anything with it. So, no duplication here! Huzzah.
2 comments:
Paul, thanks for the thoughtful commentary! Your protocol guesses are quite good. Of course, the devil is in the details, and we've made some choices to limit inappropriate correlation but also give the kind of dynamicism we need in terms of service introductions.
Note that "identity attributes" are not the only kind of data request that could be made; anything in the form of a web resource can be treated in the same way. In this sense, OAuth allows authorization of what are essentially proprietary API calls, whereas ProtectServe is aiming for distributed authorization of GETs. (We've discussed having other HTTP operations follow...this idea is very suggestive.)
This implies a fairly coarse grain of access policies. Beyond the contract terms, which *could* be arbitrarily complex but are bounded by what ordinary web users will tolerate, the access size is "one resource representation". So some granularity would get pushed into the URI space.
I wanted to keep my initial post simple, but a Relationship Manager could get fancier and also do a Service Provider job; see my response to Alec in that thread on this point. And the complexity and sophistication can go up from there. Imagine an RM also serving as a person's "Consumer agent" online, such that you can examine analytics of the data you've agreed to accept as well as the data you've agreed to share out.
Your mention of the citizen dashboard is apropos; I presented to the e-government SIG a few weeks ago at the F2F meeting. I hope we can collaborate with them more going forward.
I'm glad to hear ProtectServe doesn't step on Liberty's toes :-), but it should be noted that it's conceptually pretty close to XACML! The latter does describe a centralized authorization point, and I hope we can also use XACML underneath whatever policy expressions get standardized (perhaps involving the Policy Constraints spec?), but what we've done differently is to provide a RESTful interface.
Finally, the delegation topic is very interesting indeed -- seeing people as potential Consumers in this dance, and then standardizing contract terms that constrain what can be done with the data by delegates, starts to allow these use cases in what I hope is a natural way.
Hmm, wouldn't it possible to achieve most of the same benefits while avoiding some of the problems, by having a central place for user to *set* permissions but then "push" those policies out to the SPs ? The SPs then "simply" use and enforce those policies. The central entity then doesn't become a bottle neck and also doesn't get to know too much about actual user behaviour.
Post a Comment