RESTful Identity Services - Service Registration
By hubertsblog on Jan 14, 2008
Alright, so in the previous 2 posts I described our overall approach for RESTful identity services and the core scenario we're thinking about. In this post I'm going to explore in a bit more details what happens during the first phase of our scenario: service registration.
One word of caution: this work is evolving quite rapidly so things I present here MAY (and will) change...
In our scenario, our service provider Calendar.com needs to registers itself at our Discovery service. To do so, Calendar.com needs to upload metadata that describes its service at a well known endpoint of the Discovery service. The service metadata we use is derived from what Liberty defines in ID-WSF2.0 although we have simplified it quite a bit. We describe RESTful services with the following metadata:
- Abstract: some text describing the service
- ProviderID: a URI that (uniquely) identifies the service (e.g. something like http://Calendar.com in our example)
- ServiceContext is a complex type with the following elements:
- ServiceType: this is the type of service. An example of this would be "calendar".
- OneTimeURI: this is an element that describes whether this service supports our 1-time URI mechanism or not (described in a subsequent post)
- RegURI: this is the registration URI. This element, assigned by the DS, contains the URI that points to the service metadata. Since it is a resource (in the REST sense) it can be acted upon (e.g. an HTTP DELETE on this URI corresponds to an unregistration).
- SecurityMechID: this describes the security mechanisms supported by Calendar.com. For instance whether it support HTTPS or not.
- Options: used to describe optional features of the service
So, to register its service at the DS, Calendar.com generates the above metadata and send it to the DS at the /SvcMDRegister URI as shown in the illustration below: