C'est la vie !

RESTful Identity Services - Core Scenario

In yesterday's post I introduced the work we're doing at Sun's CTO labs on integrating identity concepts within a RESTful framework. Before I post more technical details on how we do that I thought it would be better to give an overview of our core scenario.

Let's imagine the following scenario: I book a trip on a Travel.com. Part of the features that makes this site attractive to me is that it can automatically update my online calendar, which it offers to do as soon as I have purchased my ticket. It is important to note that my calendar service (let's call Calendar.com) has no particular relationship with the travel service I use to book my trip. In fact I could change my calendar service at any time (or use another travel site). This scenario is quite simple but it will allow me to go through the various phases that need to take place.

At the highest level, 4 steps need to take place:

1. I visit Travel.com and book a ticket.
2. Travel.com offers to update my online calendar, should I have one. Since I do have such service (at Calendar.com), I accept the offer.
3. Travel.com finds out that my calendar service is hosted at Calendar.com and figures out the specifics of this service (more details on that later).
4. Travel.com contacts Calendar.com and updates my calendar there (on my behalf).
   

Many things need to happen under the hood, but one of the most interesting aspects of this scenario is the fact that we want services to be able to discover various other services that are associated with my (online) identity. In this case, the Travel site does not want to discover any calendar service, it wants to discover my calendar service.

How do we go about solving this discovery problem? One solution, proposed by Liberty Alliance, is the concept of a Discovery service. A Discovery service is an online service where a user can federate many services around his identity thus enabling their discovery. This is a powerful concept and our RESTful solution uses the same concept.

At a slightly more technical level, by including the Discovery Service notion we now have the following steps:

1. At some point in time (prior to my ticket purchase) I visited Calendar.com and was asked if I wanted to associate this service with my account (i.e. my identity) at my Discovery service (I'll leave the details on how the Calendar service knows about my Discovery service out for now).
2. When I consent, Calendar.com sends a request to associate itself with my identity there. Doing so, my calendar resource becomes discoverable by other services that can talk to my Discovery service.
3. I visit Travel.com, purchase a ticket and accept the offer to update my online calendar.
4. Travel.com performs a lookup query at my Discovery service to find out where my calendar service resides and retrieve details about it.
5. After it gets the information, Travel.com can now update my calendar that is hosted at Calendar.com.
   

In order for the last step to be possible, Travel.com needs information (metadata) about my calendar service (where it is, the security mechanisms it supports, etc.). We thus need to add a preliminary step to this sequence: Calendar.com registers its metadata at my Discovery service.

This scenario highlights the 3 core steps I described in my previous blog entry:

1. A service provider (e.g. Calendar.com) registers itself at my Discovery service and then associates itself with my identity there (at my Discovery Service)
2. A service consumer (e.g. Travel.com) discovers the location and metadata of the service that it wants to access on my behalf
3. This service consumer invokes the service provider to carry out some function (e.g. update my calendar).
   

This 3-step process corresponds to the core use case provided by Liberty's ID-WSF framework. It is also the core scenario we aim at enabling in a RESTful manner.

Posted at 10:03AM Jan 12, 2008 by Hubert Le Van Gong in Identity  |  Comments[2]