Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

intro

...

intro
Introduction and Instructions

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.

Scenario: Sharing a Calendar with Vendors (Pending)

Submitted by: Eve Maler

Online calendars are an example of personal data that is readily shared with other people in a manner that evokes VRM paradigms. Because calendar data is fairly volatile, static calendar snapshots are rarely shared; rather, a calendar feed is provided and authorized recipients can pull fresh calendar data as required. The data is often considered sensitive and is expected to be kept secure, hence "private URLs" and (minimal) ACL features offered by Google Calendar and other hosts.

In this scenario, personal online calendars are shared with "vendors" (online services) rather than other individuals, and they are shared in such a way as to allow permissioning and auditing from a central location rather than wherever the calendar is hosted. For the purposes of this scenario we'll focus on sharing a single online calendar (such as for "work", "soccer", or "travel") as a unitary Web resource, on an ongoing basis, with one or more individually-authorized recipients.

User interface mockups of a calendar-sharing interaction can be found in the initial blog post made about ProtectServe and, in somewhat more sophisticated form, slides from a speech made at an identity conference.

Following are some motivating circumstances in which calendar-sharing with vendors may make sense. (NOTE: All references to real vendors are hypothetical.)

Travel Calendar Sharing with Vendors

Alice, who is based in the Seattle area, has an online calendar that specifically contains business travel details such as flights, hotel stays, and car rentals, and since she travels quite frequently and often to international destinations, she wishes to share it with the following vendors:

...

Soliciting Timely Interactions from Vendors

Alice happens to work from home. Her typical work day is very busy, and she rarely has time to sit on hold when calling the various vendors in her life. She has a calendar that exposes the times during the day when she is free to accept a phone call or consider an invitation to a meeting or other event. She would like to share this information with the following vendors:

...

Use Case: Separate Resource Host, Relationship Manager, and Recipient (Pending)

Submitted by: Eve Maler

The most generic possible configuration of protocol endpoints solving this scenario is to have one service hosting the calendar in question, a different service getting permissioned access to it, and yet a different service functioning as the authorization manager, all of them "in the cloud" from the perspective of the user and all operating on the open Internet rather than on a corporate intranet (since our user is an individual acting on her own behalf). This configuration is illustrated below.

Image Removed

Issue: Policies Specific to the Web Resource Type

One consideration in this generic use case (and likely all other use cases for the same scenario) is the potential need to restrict, anonymize, blur, or otherwise transform the resource in question, possibly based on the unique characteristics of its content type.

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. I suggest that it is out of scope for us 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). But for realism, it may be necessary to enter into a convention that says that "busy" (vs. "free") times on a calendar designated to hold travel data means that the calendar owner is away during that period.

Sharing policies that are generic and can apply to any content type might include time- or event-bounded windows (such as "pull only once" or "pull this week only"). This question interleaves with questions about the sorts of data-usage restrictions Alice would like to put in place, for example, needing to discard the data after a certain date.

Note 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.

Issue: Authorization Manager Endpoint Discovery

The mockups linked above 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.)

Issue: Handling the Resource URL and Provisioning It to the Consumer Site

The mockups linked above imagine the simplest possible scenario: 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.

Issue: Processes By Which Consumers Meet the User's Data-Sharing Terms

Some of the vendors mentioned are big companies; we are placing a bet that standard (and machine-readable) data-sharing contract terms can 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.

For initial protocol work, I suggest we concentrate on terms that can be passively accepted, while ultimately accommodating a notion of having a Consumer present claims that it has actively met other types of terms (such as providing payment).

Scenario: Granting Service Access to a Photo Set (Pending)

Submitted by: Eve Maler

@@TBS: This differs in nature from the calendar scenario in that it gets into more OAuth-flavored situations and issues...

Issue: unique-title

(Provide commentary on the use case.)

...

Submitted by: participant-name

(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)

Use Case: unique-title (Pending)

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.)

Issue: unique-title

(Provide commentary on the use case.)

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
calendar_scenario
calendar_scenario
Include Page
ecommerce_scenario
ecommerce_scenario
Include Page
loan_scenario
loan_scenario
Include Page
distributed_services_scenario
distributed_services_scenario
Include Page
location_scenario
location_scenario
Include Page
requester_delegate_scenario
requester_delegate_scenario
Include Page
employer_scenario
employer_scenario
Include Page
custodian_scenario
custodian_scenario
Include Page
resourcemove_scenario
resourcemove_scenario
Include Page
cv_sharing_scenario
cv_sharing_scenario
Include Page
hey_sailor_scenario
hey_sailor_scenario
Include Page
hdata_scenario
hdata_scenario
Include Page
terms_scenarios
terms_scenarios
Include Page
generic_issues
generic_issues

...

Anchor
change-history
change-history
Change History

Change History