...
The generic configuration involves a consumer interacting with a separately hosted service provider in some intelligent way based on the SP's capabilities and expectations. This configuration is illustrated below.
...
| Anchor | ||||
|---|---|---|---|---|
|
Submitted by: Christian Scholz
If you look at the social networking scene today one thing is obvious already: There is lot of data online on various services
and much of this data is redundant because it is available in various copies which are usually not synced. The main area
for this problem is probably profile and friendship/contact information. On each social network or service you register
you usually have to enter your profile information again and try to find your contacts.
With the advent of more and more of such social services the amount of redundant data will grow even more and this will lead
to a acceptance problem.
The Service Catalogue idea
It is unlikely that users will centralize all their data in one place. It's more likely that data will be distributed even more.
So one problem might already be to manage all the places where data is stored about you or where services can provide
functionality on your behalf. One solution to this might be a concept called "Service Catalogue" which came up in discussions
in the open web/DiSo/DataPortability communities. The basic idea is to have a list of all these places stored under your
control which can be queried by services.
Another point is that for reducing the amount of copies of your data it is necessary to link to your data instead of copying
it (or even worse asking the user to type it in again). The Service Catalogue can serve basically as such a link list where
each service/type of data is marked up with a location (URI) and type (probably another URI). Obvious things to link to
are your profile and contact list but other things make also sense, like photos, videos, blog posts, recommendations, your
attention profile, travel information and much more.
Distributed Authorization
Now if you want to use a new service you do not even need to "register" but you simply authenticate with it (e.g. with
your OpenID) and point it to the location of your Service Catalogue.
The problem is of course how you authorize that new service to get access to all the other 3rd party services.
OAuth is one possible solution but at least if the default mechanism for retrieving a token is used this means that the user
has to be redirected to each of these 3rd party services in order to give consent for the new service to use that data.
Moreover OAuth does not contain a mechanism to define what permissions are given exactly. One can imagine that for some
services you want to give out your full profile and for others maybe just your name. Moreover this might not only apply to the
service level but also to the user level. E.g. you might want to give a contact tagged "superfriend" your full profile while
for somebody tagged "no idea how he landed on my contact list" you only want to give out basic data.
For the sake of usability what we need is a single page where you can define the relationships between that new service
and all the other services in your Service Catalogue. Moreover it would be helpful to have certain profiles stored to
quickly assign one to this new service.
Possible use cases
Here is a list of use cases which come to mind:
- User logs in to a new service and authorizes 3rd party services
- User adds a new 3rd party service to the Service Catalogue
- User changes the permissions for a service
- User manages permission profiles
...
| Anchor | ||||
|---|---|---|---|---|
|
...