Target model. Fully capable. All use cases work and best privacy properties. This model has been extensively studied in Liberty Alliance standardization work (n.b. this does not limit its applicability to Liberty ID-WSF - same concept can be implemented using other web service specifications, albeit with lesser maturity). This model addresses minimal disclosure particularly well, thus contributing to satisfying Reqs. D1.2-2.14-Priv D1.2-2.21-DataProtLaw, D1.2-6.4-Min, D1.2-7.5-Min, D1.2-7.12-CredStepUp, D1.2-6.86-Min, D1.2-9.1-SecData.
The Pull Model consists of front channel SSO layer and back channel web services layer. The "pull" refers to the strategy where attributes are requested from their authorative sources only on as needed basis. This has several benefits:
Minimal disclosure - only needed attributes are generated and shipped
Direct relationship with Attribute Authority. No intermediaries which could gain undue knowledge. This may also reduce crypto overhead as protection against the in-transit man-in-the-middle is not needed.
Intermediaries do not need to guess what attributes might be needed down the web services call chain or in a particular variant of a business process.
Fully dynamic and recursive operation that supports several Business Process Topologies. At least all forms of sequence (horizontal or vertical) and trees are supported. Support for a DAG would seem feasible. Other topologies need further study.
User U authenticates with a service provider A through her IdP1. A needs to invoke further service providers with reference to U.
If the trusted architecture uses a unique, even if random and transitory, userID throughout then such a userID would allow multiple parties to collude and correlate all data belonging to U.
The system must avoid producing correlation handles in the process.
Each service provider knows the user by a different random userID, a persistent pseudonym. And these pseudonyms are held by a mapping service. When one service provider wants to pass on the request to another service provider, it can ask mapping service for a lookup of the pseudonymous userID in the target service provider.
Given that the user's pseudonym at the other provider is encrypted in transit, this solution avoids any service providers sharing correlation handles. (N.B. In this system the two service providers invoking each other's services may still be able to directly collude, see Threat T107-LogTokLeak, but the service providers at the ends of a chain of services where chain length > 2 can not collude. The solution is to not log the tokens, see CR53-DontLogTok.)