Dashboard > The DataPortability Project > ... > Technical Specifications > Discovery - Draft 1
  The DataPortability Project Log In | Sign Up   View a printable version of the current page.  
  Discovery - Draft 1
Added by Elias Bizannes , last edited by Paul Jones on May 02, 2008  (view change)
Labels: 
(None)

Abstract

The Data Portability Blueprint consists of a number of Technical Specifications, each covering a particular aspect of the Data Portability process.

The Data Portability Technical Specification: Discovery (herein referred to as the Discovery Spec), details methods for discovering the service catalogue of a user. It does not specify the format of the store, nor does it specify the formats of the data discovered within this catalogue.

Discovery is performed using two strategies. The first is to make use of technologies already available within the user's OpenID identity provider, via the Attribute-Exchange mechanism. The second is to make use of metadata available at the user's Identity Endpoint, in a similar manner to the discovery process used by OpenID itself. The use of two strategies, whilst increasing complexity, provides flexibility for users. The first mechanism allows for transparent discovery to occur for users that have OpenID providers supporting the technology adequately. The secondary mechanism allows for manual configuration of the discovery in-lieu of support from an identity provider.

{zone:abstract-discuss}

Table of Contents

Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119(Bradner, B., "Key words for use in RFCs to Indicate Requirement Levels," .). Domain name examples use RFC2606(Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names," .).

Definitions

Note: Throughout this document, both the terms URI and URL are used. The authors' intended semantic difference is that a URL is an addressable resource that should have some representation available via a browser, whilst a URI is a unique resource that may not necessarily have a resource available at the given address (the address may not even point to an actual resource). AXAttribute Exchange - a key value pair storage system that is an extension to OpenID 2.0, whereby the OpenID server can provide values for requested keys at login time. Data Portability Service CatalogueAn addressable URL that provides details about the user's portable data services. The format of this catalogue is outside the scope of this specification. OpenIDAuthentication mechanism that revolves around the concept of a given user proving they "own" a given url, and basing their identity on that assertion. Identity EndpointUser owned endpoint that provides the initial discovery point for a user's identity. Generally the same URL provided for OpenID discovery, this page will typically provide a HTML representation that contains <meta> tags that reference keyed resources.

{zone:definitions-discuss}

Catalogue Discovery

Overview

Discovery is performed using two strategies. The first is to make use of technologies already available within the user's OpenID identity provider, via the Attribute-Exchange mechanism. The second is to make use of metadata available at the user's Identity Endpoint, in a similar manner to the discovery process used by OpenID itself. The use of two strategies, whilst increasing complexity, provides flexibility for users. The first mechanism allows for transparent discovery to occur for users that have OpenID providers supporting the technology adequately. The secondary mechanism allows for manual configuration of the discovery in-lieu of support from an identity provider.

Note that the Identity Endpoint discovery mechanism MUST be considered authoritative, as the user may be utilising this mechanism to override an OpenID provider that is not meeting their requirements.

{zone:discovery-overview-discuss}

Discovery via OpenID

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://www.dataportability.org/specifications/discovery/1.0/dp-openid-ax attribute. 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.

{zone:discovery-openid-discuss}

Discovery via Identity Endpoint

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. If this content is retrieved successfully and represents a valid HTML document, this document should be parsed and the value of any meta tags extracted. If the content specifies a meta tag with the key "dataportability.discovery1.0.catalogue", then this URL MUST be considered as the authoritative location of the user's service catalogue.

Security and Privacy

The service catalogue potentially contains a significant amount of private user data. Therefore, any provider hosting a service catalogue should consider security mechanisms to protect this catalogue.

References

[tag:OpenID Attribute Exchange 1.0 \- Final] Hardt, D., Bufu, J., and J. Hoyt, "OpenID Attribute Exchange 1.0 - Final."
RFC2119 Bradner, B., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119.


Authors' Addresses

  Paul Jones
  Faraday Media
Email: paul@faradaymedia.com
   
  Chris Saad
  Faraday Media
Email: chris@faradaymedia.com
   
  Josh Patterson
  floe.tv
Email: jpatterson@floe.tv

  • Why is this page not editable? This is a wiki!
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators