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