Abstract
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.
Status
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.Please use the template near the end of this document
...
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 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
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Pending Scenario: Sharing a Calendar with Vendors
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 URL 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 others.
In this UMA 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.
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:
- Her Visa credit-card company, Chase
Often when she tries to charge European hotel stays to her Chase Visa, the credit card company denies the charges or asks the hotel desk clerk to put her on the phone to make sure it's really her flitting around Europe and racking up big hotel bills. To let Chase know ahead of time what her travel plans are, Alice decides to share her travel calendar with them on a long-term basis so they can know ahead of time that it's likely truly Alice who's putting a Barcelona hotel stay on the card.
Note that this recipient of her data already has a lot of quite personal and sensitive information about Alice, so she's fairly comfortable giving them access to this data under certain conditions, such as refusing to accept third-party direct marketing.
It must be possible for Alice to cut off the flow of travel calendar data to Chase (even though she continues to use that card for personal purchases) when Alice is told that she has to begin using a corporate AmEx card for all business travel purchases.
- The Seattle Times newspaper delivery service
She'd like to avoid having to go to their website to put her newspaper delivery on hold every time she travels. By sharing a travel calendar with the delivery service that accurately reflects when no one will be at home, she saves one more to-do item as she prepares for each trip.
This is data she would have had to share with the service "manually" anyway, so she already had to trust the service not to rob her house while she's away. It's likely her travel calendar contains more data than the service strictly needs.
- The U.S. Postal Service
Instead of having to go to the Post Office website to fill in a mail hold form, she wants to let them know automatically. This is very similar to the Seattle Times situation, but in our project we need to solve for being able to attach different data-sharing policies and possibly have a different data-sharing lifespan between the two.
- Her mobile carrier, T-Mobile
Alice would like to be offered the option to purchase pre-paid roaming minutes when she travels overseas. By sharing her travel calendar, she can let T-Mobile know that she'll be in Brazil next month and would welcome a special offer on mobile roaming. (Note that this use case has an element of volunteered personal information to it; by positively choosing to share her information, Alice gets new opportunities to transact with vendors.)
- Her travel data social-networking sites, Dopplr and TripIt
Alice wants to keep all her "source" travel information in one place, but some of her friends and colleagues use different Web 2.0 sites to share such information. Rather than re-input all her travel destinations into Dopplr and TripIt, she'd like to let them pick up her planned locations and trip dates from her travel calendar.
Alice is unlikely to want to share more travel details with Dopplr than it can handle or than it needs. In our project, we won't put a big priority on figuring out how to get the systems to pass only minimal information to each other, but there are some open issues here that will be useful to examine. Robin suggests 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.
Today, Dopplr and other similar sites often use OAuth to share such information, but the actual data passed isn't standardized, and the protocol for creating that long-term connection between the sites is OAuth.
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 one or more calendars that expose 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:
- Her TV cable carrier, Comcast
Alice's TV cable system has stopped working, and she needs to have a Comcast repairman come over to the house to fix it. She's too busy to spend time jockeying with the customer support person on the phone about which three-hour period she might be free, so she decides to let Comcast get a limited view into her potential free times so they can book a repair time with her.
- Her general-practitioner doctor's office
Alice needs to talk to the medical assistant in her doctor's office, but it's impossible to get hold of her. The MA calls while Alice is on a telecon but can't leave a substantive message because of HIPAA laws/fears, and then when Alice calls back, of course the MA is in the middle of making a series of other calls and can't be reached. It's a "telephone tag" nightmare. She would like to share her free/busy times for the next few days so that the MA can at least pick a likely time to call her successfully.
Use Case: Separate Resource Host, Relationship Manager, and Recipient
Submitted by: Eve Maler
(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.)
Consideration: web resource handling:
Calendar format standards already account for a blurring of data details by providing the free/busy option in addition to a full-data option. It's out of scope for us to solve for filtering the calendar data cleverly (beyond the format's natural capabilities) to hide her destination, hotel, etc. (though solutions such as making events taggable 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.
We want to avoid solving for a sophisticated filtering scheme that limits the amount of calendar data she shares (other than free/busy), because this would apply only to calendars and not more generally to other types of information. However, we can innovate around time- or event-bounded windows (such as "pull only once" or "pull this week only") when the subscriber can GET the resource. 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.
As above, we want to avoid solving for a sophisticated filtering scheme on the calendar data. However, once again, we can use general data-usage policies and subscription expiration times to help limit exposure of Alice's personal data.
Scenario: (unique-title)
Submitted by: (participant-name)
Status: pending (change to accepted/deferred/rejected and note the date the decision was made)
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
Use Case: (unique-title)
Submitted by: (participant-name)
Status: pending (change to accepted/deferred/rejected and note the date the decision was made)
(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.)Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.
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 |
|---|