The first step in attribute aggregation is for the user to explicitly link his attributes together. We had a choice whether to make this linking dynamic and only established during each service request, or to make it relatively static and available for all service requests. In the interests of usability, we decided that it would be preferable for the user to link his attributes together before making a service request, and then be able to use these links automatically on each service request. This requires a new component to be conceived, called a Linking Service (LS), which is a trusted third party (TTP) used to link a user's attributes together. (In fact, the LS does not link the attributes together, but rather the IdPs that hold the attributes. In this way trust in the LS is minimised since the LS has no knowledge of which attributes each linked IdP holds, thereby maximising protection of the user's privacy.) During the linking process the user authenticates to the IdPs that he wishes to link together, (indirectly) informing them that he wishes to link the attributes they hold to those held by other IdPs. If this linking procedure did not exist, then the user would need to authenticate to multiple IdPs during the service request in order to perform the linking, and this would both complicate the protocol exchanges and make it time consuming for the user. Prior linking using the services of a LS solves these problems, and allows a user to link together his attributes just once, so that the linked attributes can then be used multiple times on different service requests.
After linking has been established with the LS, the user contacts a SP with a service request. The SP redirects the user to his chosen IdP for authentication as now (e.g. by using a Where Are You From service, or by proprietary means). The IdP performs its normal authentication procedure and returns the usual set of attributes to the SP, but in addition returns a new protocol element termed a Referral (assuming of course that the IdP has previously been contacted by and agreed to participate with the LS to link the user's attributes). In general a Referral points to another IdP that may hold additional attributes for the identified user. The Referral element in this case points to the Linking Service. Note that the IdP's authentication exchange with the user can be enhanced to ask the user if he wants to link his attributes for this SP interaction. Alternatively the user can record with the LS which SPs may use the linked IdPs, in which case the authentication exchange does not need to be enhanced. In either case, specifying the authentication protocol exchange is outside the scope of the federation and attribute aggregation protocols and is left for each IdP to independently determine.
The SP receives its usual authentication and attribute assertions from the IdP, but in addition receives the new Referral element. The SP can choose to ignore the Referral if sufficient attributes have been provided by the IdP to authorise the user's request or if the SP does not trust the LS that is referred to, but assuming that insufficient attributes have been obtained and the LS is deemed trustworthy, the SP forwards the Referral to the LS.
The LS receives the Referral from the authenticating IdP (via the SP), and sees that it is requesting attributes for a registered user of this linking service. The LS extracts information about the linked IdPs from its internal database and can now operate in one of two ways: LS aggregation or SP aggregation. With LS aggregation, the LS contacts the linked IdPs, retrieves the user's attributes, and returns the aggregated set to the SP. The SP can now make its authorisation decision.
With SP aggregation, the LS returns a set of Referrals to the SP, one Referral for each of the other IdPs that have been linked to the authenticating IdP. For each IdP deemed to be trustworthy, the SP forwards the Referral to it. Each IdP interprets the Referral, locates attributes for the identified user, and returns them to the SP. The SP aggregates together all of the returned attributes and makes it authorisation decision based upon them.
A pre publication copy of our conceptual model which is to be published in the Future Generations Computer Systems in 2010 is available from here. If you wish to comment on this revised conceptual design please send any comments to our mailing list.
A previous version of our conceptual model document is available from here.
Our Initial Conceptual design document which documented our inital conceptual design for attribute aggregation can also be downloaded here .