Multiple identities are required to establish sufficient levels of trust and to provide an audit trail of operations and transformations.
In their model, a SOAP message request will contain a WS-Security header with at least two SAML assertions S(p) and S(a1) - S(p) identifies the originator of the transaction (typically a user in a browser session), and S(a) identifies the Web service actor sending the request. The model is shown below.
If the resource being accessed through the web services is itself not associated with a given identity (e.g. my calendar, or my profile, etc) - the above model of two identities in a request can be sufficient. As well, even for identity-based resources, if the originating identity S(p) is the same as the 'owning' identity (i.e. I'm the one initiating a request for my own identity attribute) then the above model is fine - 2 identies in the request are enough.
But, if the identity initiating the request for some identity attribute is not the same as the identity associated with the attribute, then more identities may be required in the request. For instance, if my wife is trying to access my current geolocation (stop stalking me, I said I would be home at 10!), and if I've defined permissions so that not everybody can see where I am, then the request will necessarily specify both her and my identities (as well perhaps as the requesting application (e.g. TrackYourCheatingSpouse.com).
It was just these sort of multi-identity request scenarios that motivated the development of the People Service in Liberty Alliance ID-WSF 2.0.
You can think of the People Service as the place to track/manage your connections to all of theose friends/family/colleagues for whom you might want to grant access to your identity attributes. Instead of maintaining such a buddy list at each application, you maintain it centrally.
Social graph portability before it was cool.
No comments:
Post a Comment