...
This document is currently under active development. Its latest version can always be found here. See the Change History at the end of this document for its revision number.
Editors
- Hasan Ibne Akram (lead editor)
- Gerald Beuchelt
- Domenico Catalano
- Maciej Machulak
- Eve Maler
- Christian Scholz
- Thomas Hardjono
Intellectual Property Notice
The User-Managed Access Work Group operates under Option Liberty and the publication of this document is governed by the policies outlined in this option.
...
Table of Contents
| Table of Contents |
|---|
...
...
| Anchor | ||||
|---|---|---|---|---|
|
This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments, and outlines technical issues raised thereby.
Please use the scenario template near the end of this document copy and revise an existing scenario in adding new scenarios and subordinate use cases. Each scenario is created as a separate child wiki page with a name like xyz_scenario and then linked from here. Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:
- Pending: Initial status when first submitted
- Accepted: Needs to be accounted for in UMA V1 and/or its associated compliant implementations
- Deferred: Relevant to the problem space; may be considered in future versions
- Rejected: Out of scope
Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.
...
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
...
Submitted by: participant-name
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
...
Submitted by: participant-name
(Provide description of a use case matching this scenario with all technical particulars, such as the topological configuration of protocol endpoint entities, potential wireframes, listings and assessments of technical issues, and anything else helpful.)
...
Following are discussions of technical issues raised by one or more scenarios and use cases. Acceptance of a scenario or use case will imply agreeing to develop a satisfactory solution to applicable issues.
Issue: Policies Specific to the Web Resource Type
Related to: calendar scenario, location scenario
There is a potential need to restrict, anonymize, blur, or otherwise transform a shared resource, possibly based on the unique characteristics of its content type.
With respect to calendar resources, the premier calendar format standard already accounts for a blurring of data details by providing a "free/busy" option in addition to a full-data option. It feels like it should be out of scope to solve for filtering the calendar data cleverly (beyond the format's natural capabilities) to hide Alice's destination, hotel, etc. (though generic solutions such as making events taggable, and then filtering on the tags in a relationship manager interface, come to mind). An "identity oracle" approach (filtering the data into a completely different type) might be necessary if what Alice is trying to convey is simply "don't deliver my newspaper on these days" vs. "here's all of my travel information".
In the Controlling Two-Way Sharing of Location Information scenario, note that FireEagle allows a user to choose to share locations only at the city level, and this level happens to be chosen for the connection that authorizes Dopplr to read the FireEagle location (a different level can be chosen for each application that reads location from FireEagle). As it happens, Dopplr does not offer the same policy capability. Without having to teach UMA generically about all the possible policy options specific to all the kinds of information in the world, is it possible for each Host to teach each AM about the policy options it offers, in some way that lets the the relationship manager application surrounding the AM present user interface options to see and select these policies? Seeing may have less protocol impact than selecting, and seems to be a minimum value-add if the goal is to allow OAuth users to get a global view.
Some data-usage policies and terms may possibly have an interaction with some resource types, such as requiring recipients to discard volatile data after a period dictated by the data's type.
It has been observed that if fine-grained calendar filtering were a solved problem, different calendar sites could be shared with different friends as a way of managing minimal disclosure through indirection.
...
Related to: calendar scenario, photo set scenario
The mockups linked in the calendar scenario imagine that the user's authorization manager endpoint (what we imagine Alice will perceive as the name of her relationship management service) will be handled as if it were an OpenID, with introductions to popular relationship manager services offered in an array by potential UMA service providers much in the way that the RPX solution presents options. (The user always has the ability to self-host an authorization manager endpoint, similarly to self-hosting an OpenID provider – and they might even be colocated.)
...
Related to: calendar scenario, location scenario
The mockups linked in the calendar scenario imagine the simplest possible situation: The Consumer site literally asks for exactly the kind of information it needs, and the user copies and pastes a URL into a field.
This is how calendar feeds, photo streams, RSS feeds, and other such resources are shared today; it works but we need to consider its scalability to arbitrary types of information. There are several challenges here: The Consumer's ability to handle the information, its way of expressing the desire/need for the correct information, and the user's (or user agent's) ability to provide it in a convenient and correct fashion.
In addition, the relationship manager interface is shown having some knowledge of that resource as a unique object. We need to consider how to let the AM and SP communicate about this information appropriately.
In the case of the photo set scenario, note that in OAuth usage today, the resource-based interaction is often accomplished silently from the user's perspective: the desired combinatorial effect simply "happens" as if the feature that was "outsourced" to a third-party app were native. Perhaps this is possible in the UMA approach.
...
Related to: calendar scenario, location scenario
Some of the vendors mentioned in the calendar scenario are big companies; can standard (and machine-readable) data-sharing contract terms be developed and pre-negotiated such that, when such contracts are offered by an individual, they are likely to be accepted and met? Small companies such as a modest medical practice may need a human-accessible interface and the option of an "I Agree" button so that the person manually fielding Alice's offer of data can complete the transaction.
...
Common Building Blocks (Dimensions)
As a further refinement to help us in classifying and prioritizing the use cases, we would like to add a section to each use case describing the building-block features or dimensions that are present in a given use case. The current list of features or dimensions are as follows:
Dimension | Description | Example |
|---|---|---|
Nature of protected resource | A description of the sorts of protected resources at hosts in this scenario, and the scope values that might be applicable, ideally with real-life supporting evidence. Protected resources appear to fall on a continuum from API endpoint (such as status updates) to content-oriented (such as photos), and further, typical actions on them may usefully be classified in terms of how RESTful they are. | In the location services scenario, protection of a location service (a set of one or more API endpoints) might involve scope values such as "write location data", "read precise location data", and "read location data at a city level". |
Sharing models | A description of what sorts of access or sharing the scenario facilitates. Person-to-self sharing occurs when an authorizing user shares access with a service that is acting directly on the same user's behalf (a la "three-legged" OAuth). Person-to-service sharing occurs when an authorizing user shares access with a legal person operating a service that is acting on its own behalf (a la "two-legged" OAuth, where the client is autonomous). Person-to-person sharing (also known as "Alice-to-Bob sharing") occurs when an authorizing user shares access with a different natural person. (@@Fourth category of "person-to-rep sharing" where the autonomous company's service is operated by a human company rep?) | The location services scenario is an example of person-to-self sharing. The calendar scenario is written to explore person-to-self and person-to-service (@@and person-to-rep?) sharing options, but could also apply to person-to-person sharing. |
Nature of policies and claims | A description of the types of policies, and any resulting claims requested, that might be suitable for this scenario and its use cases. | The terms negotiation scenarios discuss likely claims needed in the course of assessing a requesting party's right to get access. |
Cardinality | An accounting of whether the scenario or any of its use cases necessarily involve multiple instances of any of the UMA entities. | The financial loan scenario by its nature involves a requester having to access multiple protected resources, likely from different hosts. The scenario related to moving resources by its nature involves two different AMs: the user's previously chosen AM and their newly chosen one. This information is often usefully conveyed with an architectural diagram along with descriptive text. |
Colocation | A description of likely cases where real-world applications might want or need to support multiple UMA endpoints. | The health data scenario tends to involve actors that serve as both hosts and requesters. The trusted claims scenario proposes that an application offering AM services might also need to be a requester in order to access the UMA-protected claims of some other ("primary") requester. |
Host-AM relationship | An accounting of how hosts and AM come to meet and trust each other in this scenario or its use cases. Dynamic discovery might be required or forbidden. AMs and hosts respectively might need to be well-known, or at least dynamically qualified before the connection is made. | The health data scenario might have a short list of approved AMs to which many hosts around the world may need to dynamically connect as soon as a new patient needs medical care. |
Protected resource discovery | A description of the anticipated method(s) by which a requester learns about a resource of interest to them. The methods may have a dynamic element to them or may require reconfiguration. The methods may or may not involve direct human assistance. | The calendar scenario could mention that most calendar feeds are shared today through URL copying and pasting. |
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
| Include Page | ||||
|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
| Change History |
|---|