Monday, December 10, 2007

ID-WSF and the VRMish "Magazine subscription use-case"

Update 2: in a comment, Robert clarifies and expands. First, that ID-WSF allows for 'first level permissions' to be defined at the Discovery Service, i.e. the user can control which requestors are even allowed to find their identity services, much less actually obtain identity. Secondly, interaction can happen either through browser redirects, or through the back-channel. Robert points out that, if the user is online and available, the redirect option is simpler. Agreed, but there can be security advantages to using a separate communication channel than the browser.

Update: fixed below where I mistakenly attributed the 'push out new address' operation to Mobi.us - this actually performed by MYMailingAddress.com.

Summary

Alice is a customer of British Airways, and has BA's monthly in-flight magazine delivered to her work mailing address (as the bulk of her travel is work related). Alice maintains her mailing address at an online Identity Provider MyMailingAddress.com. If and when Alice changes jobs, changing her address at MyMailingAddress.com will serve to automatically change all copies of the address held by the various mailers she has signed up for.

Actors

  1. Alice, a frequent flyer with British Airways.
  2. Mobi.us, Alice's cellular provider.
  3. MyMailingAddress.com, the Identity Provider at which Alice stores her delivery/shipping address.
  4. BritishAirways, the airline wants to know if and when Alice's shipping address changes so that her subscription to the BA in-flight magazine Impressions can be delivered without interuption

Sequences

These following sequences describe how Liberty Alliance ID-WSF could be applied to support the use case. There are two phases, the first in which Alice facilitates BA getting her mailing address the first time, followed some time later by BA automaticaly receiving her new address when it changes.

Initial

  1. On a business trip, prompted in the departure lounge by an offer for additional miles if she subscribes to BA Impressions, Alice uses her phone to navigate to the BA mobile site
  2. After asking her for consent, BA redirects Alice to Mobi.us, using SAML to ask Mobi.us for Alice's authentication
  3. After authenticating Alice, Mobi.us sends her browser back to BA with a SAML assertion carrying a pseudonym for Alice (specific to the Mobi.us/BA connection). Also in the SAML assertion is information about Alice's Discovery Service (DS) – the place where BA can go to find out where Alice's Personal Profile Service is – this the place to get her mailing address.
  4. BA asks Alice for her consent for it to discover her Personal Profile. She gladly gives it, as this will mean she doesn't have to enter it on the phone herself.
  5. BA queries Alice's DS for the location of her Personal Profile, specifying it's her work address it is interested in (as guided by Alice) as a search parameter. At the same time as making this request, BA asks to be notified if and when Alice's address changes in the future.
  6. Alice's DS returns to BA Alice's work address. Likely accompanying the data itself are the associated obligations BA assumes, e.g. allowed uses, deletion rules, etc.
  7. BA displays the address to Alice and asks 'Use this one?'
  8. Alice notices that the address has an old office building listed (she having changed departments), she changes that bit through BA's interfaces (the phone OK for entering numbers)
  9. BA sends the changed address back to Mobi.us
  10. 10.Mobi.us, uncertain about whether it should accept the changed data, reaches out through the ID-WSF Interaction Service (IS) to send Alice an SMS asking for guidance
  11. Alice indicates Mobi.us should accept the changed data and store the new building.Her consent is routed back through the IS.
  12. BA now has Alice's mailing address and Alice enjoys reading on a monthly basis about up-scale hotels in exotic locations her company's travel policy will never allow her to stay in.
Later On
  1. Alice switches companies, her new role has similar travel load so she still wishes to receive BA's magazine.
  2. Alice visits her account management page at MyMailingAddress.com
  3. She enters her new work mailing address.
  4. Based on the previously subscription created when BA first obtained Alice's mailing address, MyMailingAddress.com pushes Alice's new mailing address to BA(and other chosen mailers).
  5. Alice receives Impression magazine without interuption.
Notes
  1. ID-WSF can work much the same way for all the other slices of Alice's identity, e.g. calendar, wallet, geo-location, reputation, etc. It's all about discovery & invocation of identity services, with appropriate security & privacy.
  2. there need be no existing trust and/or business relationship between MyMailingAddress.com and BA. Mobi.us can effectively broker trust between the two of them.
  3. ID-WSF supports variations where Alice's phone can play a more active role, e.g. either or both of Discovery Service & Personal Profile Service could hosted on her phone

1 comment:

Robert said...

Good use case and description thereof. One minor remark: I think that BA will simply contact the DS to find the Profile Service and that then the *DS* will ask Alice for consent (but I suspect that most users would be happy to provide up-front consent to the use of the DS to all parties that are "trusted" by the IdP/DS). And the Profile Service will probably ask for consent to give out the address.

Another remark: if the user (Alice) is browsing it is typically easier for everybody to do user-interactions with redirects than to use the Interaction Service (as much as I like it). In your use case Alice is on-line and browsing so when BA "writes" the corrected address the Profile Service can do an user-interaction dance.