Dashboard > The DataPortability Project > ... > Technical Specifications > DP-IMPL-001 - Service Catalogue Discovery
  The DataPortability Project Log In | Sign Up   View a printable version of the current page.  
  DP-IMPL-001 - Service Catalogue Discovery
 Browse Space
Added by Paul Jones , last edited by Paul Jones on May 02, 2008  (view change)
Labels: 

Overview

The service catalogue, as described in DP-REC-002 - Service Catalogue, provides the root of all further Data Portability operations, discovery is essential to a seamless user experience. Performed via a number of methods, it is intended that this may later be extensible so as to ensure that the experience remains seamless.

This implementation describes methods for locating a service catalogue from three possible locations:

  • XRDS (XRDS-Simple) Discovery. Possibly as part of discovery of the user's Identity URL (be that OpenID enabled or otherwise)
  • OpenID Attribute Exchange
  • A user specified location

Implementation Details

The following sections describe each of the potential methods for discovering the location of a Service Catalogue for a given user.

Discovery via XRDS(-Simple)-Auto-Discovery as for discovery of Identity endpoints

Discovery is initiated by any application that wishes to access the DataPortability Endpoints for a user. When processing either the login for the user, or an action that requires information from the user's portable catalogue, the application MUST retrieve the content available at the normalised Identity Endpoint, where the normalisation is the same as that performed for OpenID 2.0 endpoints.

This process is as described in XRDS-Simple and OpenID-Yadis and uses the discovery mechanisms described there. The XRDS file found is probably the same XRDS file used for OpenID Delegation.

If XRDS discovery falls back to reading the HEAD section of the HTML document at the location provided, then optionally an additional key may be included "dataportability.discovery1.0.catalogue". If this key is included, then this URL MUST be considered as the authoritative location of the user's Service Catalogue.

Discovery via OpenID Attribute Exchange

Discovery is initiated by any application that wishes to access the DataPortability Endpoints for a user. When processing the login for the user, the consumer application MUST utilise OpenID Attribute Exchange, and request the http://axschema.org/x/discovery/xrdsattribute. The OpenID server, if it supports this attribute, MUST return a valid URL. If the OpenID server does not support the attribute, it MUST fail as per the OpenID Attribute Exchange specification.

Discovery from User Specified Location

Discovery is initiated by any application that wishes to access the DataPortability Endpoints for a user. When processing the login for the user, or at any point, the application requests the user enter the location of their Service Catalogue. This catalogue may then be accessed by the requesting application.

Selection Rationale

XRDS-Simple and OpenID-Yadis is fairly well understood and gaining traction as a way of associating or delegating a well known URL (eg My blog url) with an OpenID (eg an OpenID provider like MyOpenID). As this XRDS is already being found for OpenID use, it's natural to add additional services to it. It's effectively an extension of the third option of simply asking the user because it allows the user to put in a well known URL and then using that to find the actual location of the XRDS. It is anticipated that the actual creation of the XRDS file and insertion of the discovery parts would be handled by code such as a Blog plugin or by the social network that provides the home page that the user points to.

Discovery via OpenID Attribute Exchange is included to allow for situations where the user's home page and OpenID provider are one and the same. Even there though, the OpenID Service Provider could also provide the XRDS and XRDS Discovery. It also allows for the situation where the Service catalogue is only provided once the User and Relying Party have been verified. Although this technique has appeal it also has problems. Not least of which is that OpenID AX is poorly supported with very few current implementations.

Why this implementation was selected over other possible implementations, including:

  1. Brief details of other possible implementations.
  2. Why this implementations is better.

Details of Adoption

Forming a vital component of the final approval process, this section should detail actual real-world implementations of this suggested method; hence showing adoption of the proposal.

Action Group Backing 

Members of the action groups that back this implementation should be listed here, as a formal tracking of support for the implementation.

Comments  (Hide Comments)

Is it appropriate to fill in what you might expect in the XRDS file (expected types) and what the endpoints might look like. Even if it is just a collection of links to the other docs?

Posted by Chris Saad at Apr 19, 2008 11:19

I think the way that the Service Catalogue is laid out definitely needs to be detailed - however, this isn't really the right specification to do that in. I believe we'll need a separate implementation specification that details how we use XRDS-Simple to achieve the goal of cataloguing services to be used in DataPortability applications.

Posted by Paul Jones at Apr 19, 2008 17:48

I think the AX key name should be something like http://axschema.org/x/discovery/xrds axschema.org exists to act as a clearing house for AX key names so we ought to use them rather than invent our own. That also puts the onus on someone else to make that URL permanent.

Posted by Julian Bond at Apr 20, 2008 04:59

Certainly. I'll update that in now. That format exactly matches the ones proposed at axschema I take it?

Posted by Paul Jones at Apr 20, 2008 05:01

We discussed this a bit in Skype and I wonder if we really need the AX part. This seems not to be widely supported and even creating a test scenario for it means first setting up your own openid server (and the AX part also seems not to be documented that well).

Wouldn't it be sufficient to use the XRDS/YADIS file for this to list your (public) services along with your openid server?

This could have an additional link to a protected (OAuth) XRDS file which can be read later then. This would also limit the technologies in use here.

The question is what the correct service type for this might be. Is it http://xrds-simple.net/core/1.0 ?

Posted by Christian Scholz at Apr 30, 2008 16:00
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators