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 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 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 and book a ticket.
  2. offers to update my online calendar, should I have one. Since I do have such service (at, I accept the offer.
  3. finds out that my calendar service is hosted at and figures out the specifics of this service (more details on that later).
  4. contacts 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 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, 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, purchase a ticket and accept the offer to update my online calendar.
  4. 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, can now update my calendar that is hosted at
In order for the last step to be possible, 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: 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. registers itself at my Discovery service and then associates itself with my identity there (at my Discovery Service)
  2. A service consumer (e.g. 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.

[Trackback] Bookmarked your post over at Blog!

Posted by restful on January 14, 2008 at 09:03 AM PST #

[Trackback] Bookmarked your post over at Blog!

Posted by restful on February 06, 2008 at 05:49 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« February 2015