Liberty Alliance: Difference between revisions
Paulmadsen (talk | contribs) No edit summary |
Joe.andrieu (talk | contribs) (reversion) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
'''Liberty Alliance & VRM''' | '''Liberty Alliance & VRM''' | ||
The Liberty Alliance defines | The Liberty Alliance defines its ID-Web Services Framework (ID-WSF) for the registration, discovery, and invocation of identity services - SOAP-based web services into a user's identity. | ||
In effect, ID-WSF provides plumbing for distributing the various identity attributes of a user (assuming/enabling that the user has approrpiate control over such sharing). Too date, Liberty has defined how ID-WSF can be used for sharing personal profile, gaming prefs, presence, geolocation, calendar, etc. | In effect, ID-WSF provides plumbing for distributing the various identity attributes of a user (assuming/enabling that the user has approrpiate control over such sharing). Too date, Liberty has defined how ID-WSF can be used for sharing personal profile, gaming prefs, presence, geolocation, calendar, etc. | ||
If you think of a personal RFP as just a different slice of a given user's identity, then ID-WSF could provide one (of many possible ) mechanism for sharing this slice in a privacy and security- | If you think of a personal RFP as just a different slice of a given user's identity, then ID-WSF could provide one (of many possible e.g. OpenID DTP) mechanism for sharing this slice in a privacy and security-enhanced manner. | ||
I hope to fill in the specifics of how this might work on this page going forward but the bare basics are as follows: | I hope to fill in the specifics of how this might work on this page going forward but the bare basics are as follows: |
Latest revision as of 18:37, 18 June 2007
Liberty Alliance & VRM
The Liberty Alliance defines its ID-Web Services Framework (ID-WSF) for the registration, discovery, and invocation of identity services - SOAP-based web services into a user's identity.
In effect, ID-WSF provides plumbing for distributing the various identity attributes of a user (assuming/enabling that the user has approrpiate control over such sharing). Too date, Liberty has defined how ID-WSF can be used for sharing personal profile, gaming prefs, presence, geolocation, calendar, etc.
If you think of a personal RFP as just a different slice of a given user's identity, then ID-WSF could provide one (of many possible e.g. OpenID DTP) mechanism for sharing this slice in a privacy and security-enhanced manner.
I hope to fill in the specifics of how this might work on this page going forward but the bare basics are as follows:
- Joe maintains his RFPs at example.rfp.com
- example.rfp.com registers the fact that it is Joe's electronics RFP server at Joe's Discovery Service
- Joe visits example.etoys.com by SSO'ing in from his IDP
- example.etoys.com sends a SOAP call to query Joe's Discovery Service for 'VRM providers that cover electronic goods' (Joe's IDP tells example.etoys.com where Joe's Discovery Service is)
- Joe's Discovery Service returns the example.rfp.com endpoint (and appropriate credentials to use in any message sent there) in its response to example.etoys.com
- example.etoys.com sends a SOAP call to query example.rfp.com for Joe's electronics RFPs
- example.rfp.com responds (after checking permissions previously set by Joe, if unclear, it can use the Interaction Service to clarify policy with Joe) with Joe's electronics RFPs (not sending the clothing RFPs etc) formatted as an XML doc (according to VRM defined schema)
- example.etoys.com parses Joe's RFP and creates appropriate offers for Joe, e.g. not showing him the iPod deal and only showing Samsung plasmas
Notes:
- example.etoys.com could, guided by Joe, create an RFP and push it to Joe's VRM server for future retailers.
- Much of ID-WSF's value (and complexity) is in ensuring that the above sequence can happen without all providers learning a single identifier for Joe, and thereby enabling subsequent collusion.
- the providers can 'negotiate' appropriate security characteristics of the above messages, e.g. TLS and message-level signing, or no security at all, etc
- Joe's VRM service (or his discovery service, etc) could be hosted on his phone etc - there is no built-in presumption of network providers
- Liberty's People Service would enable a 'Gift Registry' use case where Joe is able to view the RFP's of his friend Alice (assuming Alice wants this to happen).