Goal
The goal of this document is to describe the process of logging in to a service and obtaining the service catalogue for this user. The login can be done in the context of a registration for a new social network. The service catalogue is a list of locations referenced by URLs to locations where the user has data about himself stored already (such as profile information or contact lists).
This document describes how this service catalogue looks like and how it is discovered. What a service can do with the obtained data is the topic of other Best Practices Documents. This aims to be the general foundation for most of them. Data Portability begins right from when a user logs into the system. The best possible user experience will involve applications being able to automatically discover as much information as possible.
Use Cases solved by this document
- UC001 Member registers with a new Social Network (without the sub use cases)
Terms
- User - a user who wants to have access to his data on different services.
- OpenID Service Provider - An OpenID Provider.
- Data Provider - a service which provides portable data (e.g. profile or contact information)
- Data Consumer - a service which wants to access data from a Data Provider.
- Service Catalogue Provider - a service which provides the Service Catalogue for a user.
- Service Catalogue - a list of services for a particular user. The format is XRDS-Simple and as described in DP-REC-002 - Service Catalogue
Please note, that one service can be of course Data Provider, Consumer, OpenID Service Provider and Service Catalogue Provider together (or any subset).
The Process
Main success scenario
- The user logs in via OpenID to a Data Consumer
- The Data Consumer authenticates the user as described in the OpenID specification
- The Data Consumer obtains the Service Catalog for the user from the Service Catalogue Provider as described in DP-IMPL-001 - Service Catalogue Discovery.
- The Data Consumer reads the Service Catalogue and filters those Services of Data Providers it is interested in.
- The Data Consumer contacts those Data Providers and reads the data.
This process ends here. The various types of data and what to do with them will be documented in further Best Practices documents.
Exceptions
4a. A service endpoint is protected by OAuth
4a1. The system authorizes the access to a service endpoint as described in DP-REC-003 - Portable Data Authorisation
2a. The user cannot be authenticated
2a1. The process stops here unless the system implements other means of authentication such as providing the user with an OpenID of the system.
Technical Requirements
Requirements for a Data Consumer
A Data Consumer MUST obtain the service catalogue as described in DP-IMPL-001 - Service Catalogue Discovery.
When reading data it MUST obey the rules for authorization of data endpoints as described in DP-REC-003 - Portable Data Authorisation.
Requirements for a Data Provider
A Data Provider MUST store the URLs of data endpoints for a particular user in the Service Catalogue of that user on the Service Catalogue Provider as will be described in the Best Practices document XXX about Service Catalogue Updates.
Requirements for a Service Catalogue Provider
A Service Catalogue Provider MUST implement the Discovery mechanism as described in DP-IMPL-001 - Service Catalogue Discovery. A Service Catalogue Provider CAN choose to protect the Service Catalgue as described in DP-REC-003 - Portable Data Authorisation.
Implemenation details
Services which provide data such as profile or contact list information MUST provide their data endpoints in an XRDS file as describes in DP-REC-002 - Service Catalogue. Those services need
This can be either in the XRDS file used for YADIS or in a separate one which either is obtained via OpenID AX or as link from the initial XRDS file. Services MUST provide a way for the user
Used Technologies
OpenID
DP-REC-002 - Service Catalogue.
DP-IMPL-001 - Service Catalogue Discovery (XRDS Discovery with OpenID AX)
DP-REC-003 - Portable Data Authorisation (OAuth)
Issues
- Technical recommendation for OpenID is missing
- How do we link to policy requirements? E.g. "If a data endpoint cannot be authorized the Data Consumer MUST NOT use this URL for any purpose." just a hypothetical example but maybe we need to link policy and technical bits a bit
- Where do we put the remarks from Julian about XRDS, FOAF, MF and so on? Should they be on this document or on the individual technical specs? I tried here to just use links to those and did not really name the technologies too much.
- A Data Provider MUST also provide some data in those areas we are interested in (mostly profile and contact data for now) but where will this be listed? I would propose that it's in the particular Best Practices Documents about them.