Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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

Eve Maler

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


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.

Please use the scenario template near the end of this document in adding new scenarios and subordinate use cases. 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:

  • 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 send her an event invitation for a repair slot.
  • 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 (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.

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.

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 SPs much in the way 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: unique-title (Pending)

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


Change History

Version Date Comment
Current Version (v. 9) Jul 23, 2009 18:08 Eve Maler
v. 60 Oct 05, 2010 22:08 Eve Maler:
Migration of unmigrated content due to installation of a new plugin
v. 59 Oct 05, 2010 22:08 Eve Maler:
Migration of unmigrated content due to installation of a new plugin
v. 58 Oct 05, 2010 22:08 Eve Maler:
Migration of unmigrated content due to installation of a new plugin
v. 57 Oct 05, 2010 22:08 Eve Maler:
Migrated to Confluence 4.0
v. 56 Oct 05, 2010 22:08 Eve Maler:
Filled in some links to specific scenarios in examples of dimensions.
v. 55 Sep 30, 2010 12:44 Thomas Hardjono
v. 54 Sep 30, 2010 12:41 Thomas Hardjono
v. 53 Sep 30, 2010 12:34 Thomas Hardjono
v. 52 Sep 30, 2010 12:28 Thomas Hardjono
v. 51 Sep 30, 2010 12:25 Thomas Hardjono
v. 50 Sep 30, 2010 12:14 Thomas Hardjono
v. 49 Sep 22, 2010 10:56 Thomas Hardjono
v. 48 Sep 20, 2010 16:43 Thomas Hardjono
v. 47 Sep 20, 2010 16:42 Thomas Hardjono
v. 46 Sep 20, 2010 16:40 Thomas Hardjono
v. 45 Sep 20, 2010 16:19 Thomas Hardjono
v. 44 Sep 20, 2010 16:11 Thomas Hardjono
v. 43 Feb 16, 2010 10:35 Eve Maler
v. 42 Feb 16, 2010 10:29 Eve Maler:
Added "Hey, Sailor" (advertising a resource) scenario
v. 41 Jan 28, 2010 19:35 Eve Maler
v. 40 Jan 25, 2010 00:20 Eve Maler
v. 39 Jan 24, 2010 10:03 Maciej Machulak
v. 38 Jan 13, 2010 12:44 Eve Maler:
Broke out the terms negotiation scenarios into a new top-level section
v. 37 Jan 09, 2010 18:16 Eve Maler
v. 36 Jan 09, 2010 18:07 Eve Maler
v. 35 Jan 09, 2010 18:05 Eve Maler:
Revised editors, put generic issues into its own file
v. 34 Dec 16, 2009 17:48 Hasan
v. 33 Dec 16, 2009 17:43 Hasan
v. 32 Dec 16, 2009 17:41 Hasan
v. 31 Dec 04, 2009 17:32 Eve Maler
v. 30 Dec 04, 2009 15:38 Eve Maler
v. 29 Dec 04, 2009 15:33 Eve Maler
v. 28 Dec 03, 2009 11:18 Maciej Machulak
v. 27 Nov 21, 2009 10:17 Eve Maler
v. 26 Oct 08, 2009 19:11 Eve Maler:
Added reference to module for Requester Delegate scenario
v. 25 Oct 04, 2009 20:16 Eve Maler:
Took out "related to" links from Issues to specific scenarios; expanded the Issue related to "terms"; revised to use new terminology
v. 24 Sep 18, 2009 06:34 Eve Maler
v. 23 Sep 18, 2009 05:47 Eve Maler
v. 22 Sep 18, 2009 05:14 Eve Maler
v. 21 Sep 08, 2009 14:00 Domenico Catalano
v. 20 Sep 07, 2009 09:50 Christian Scholz:
replaced old version of distributed social networking scenario with new one about distributed services (and used inclusion)
v. 19 Sep 06, 2009 22:43 Eve Maler
v. 18 Sep 06, 2009 22:38 Eve Maler
v. 17 Sep 06, 2009 22:28 Eve Maler
v. 16 Sep 01, 2009 18:06 Eve Maler
v. 15 Sep 01, 2009 14:23 Hasan
v. 14 Sep 01, 2009 14:19 Hasan
v. 13 Aug 13, 2009 05:42 Christian Scholz:
added new scenario about Distributed Social Networks
v. 12 Aug 11, 2009 21:30 Eve Maler:
This and all previous revs are "editors' drafts" and have not been approved by the group
v. 11 Jul 25, 2009 16:29 Eve Maler
v. 10 Jul 25, 2009 09:51 Eve Maler
v. 9 Jul 23, 2009 18:08 Eve Maler
v. 8 Jul 23, 2009 16:43 Eve Maler
v. 7 Jul 23, 2009 16:34 Eve Maler
v. 6 Jul 23, 2009 16:30 Eve Maler
v. 5 Jul 23, 2009 15:14 Eve Maler
v. 4 Jul 23, 2009 13:55 Eve Maler
v. 3 Jul 23, 2009 13:33 Eve Maler
v. 2 Jul 23, 2009 13:31 Eve Maler
v. 1 Jul 23, 2009 12:53 Eve Maler
  • No labels