...
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 | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
| 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 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:
...
Edit the descriptions of technical issues and scope questions to reflect (or point to) group decisions about how to handle them.
| Anchor | ||||
|---|---|---|---|---|
|
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.
...
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 read 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.
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
Today, many Web 2.0 services are beginning to offer users features that depend on connections with other third-party services, using OAuth to forge the connection. A classic example is configuring your photo-hosting site to use some other photo-printing site to print your photos. Whereas the Sharing a Calendar with Vendors scenario primarily focuses on sharing data whose "substance" (your calendar entries) vendors then "consume" to give you interesting service, this scenario primarily focuses on granting service access to other services in order to get combinatorial effects from the service features themselves.
In this scenario, access to photos is shared with other services that can do interesting things with them, in such a way as to allow permissioning and auditing from a central location rather than wherever the photos are hosted. Since it is just as likely that multiple photos might want to be subjected to this treatment as a single photo would be, we'll assume a set of them. Each third-party service is intended to be granted access separately, on possibly unique terms.
This scenario is a bit similar to the Sharing a Calendar with Vendors circumstance in which calendars are shared with Dopplr and TripIt.
Following are some motivating circumstances in which photo access may make sense. (NOTE: All references to real vendors are hypothetical.)
- Making a feed or stream of photos available for printing and mailing to a recipient
This situation is based on that described in item #8 (alternative) of the photo-sharing scenario from the IIW8 Use Case Selection and Metrics session in May 2009: "Grandma doesn't do stuff online, but subscribes to a service that prints and sends her photos. Peter wants to give printing/sending access rights to the service." You, as the photo owner, may want to commit the printing service not to use or further share the photos beyond this task, and may want to audit their periodic retrievals of photos for printing and mailing.
- Using a service that creates photo thumbnails and other reduced-size versions
In this case, you are giving "read" access to your photos, but also "write" access to hold the results of the processing. This is perhaps similar to the way some OAuth-connected location services can either read your location from, or write your location to, each other.
@@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.)
...
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.)
...
| Anchor | ||||
|---|---|---|---|---|
|
Submitted by: Eve Maler
Today, many Web 2.0 services are beginning to offer users features that depend on connections with other third-party services, using OAuth to forge the connection. A classic example is configuring your photo-hosting site to use some other photo-printing site to print your photos. Whereas the Sharing a Calendar with Vendors scenario primarily focuses on sharing data whose "substance" (your calendar entries) vendors then "consume" to give you interesting service, this scenario primarily focuses on granting service access to other services in order to get combinatorial effects from the service features themselves.
In this scenario, access to photos is shared with other services that can do interesting things with them, in such a way as to allow permissioning and auditing from a central location rather than wherever the photos are hosted. Since it is just as likely that multiple photos might want to be subjected to this treatment as a single photo would be, we'll assume a set of them. Each third-party service is intended to be granted access separately, on possibly unique terms.
This scenario is a bit similar to the Sharing a Calendar with Vendors circumstance in which calendars are shared with Dopplr and TripIt.
Following are some motivating circumstances in which photo access may make sense. (NOTE: All references to real vendors are hypothetical.)
- Making a feed or stream of photos available for printing and mailing to a recipient
This situation is based on that described in item #8 (alternative) of the photo-sharing scenario from the IIW8 Use Case Selection and Metrics session in May 2009: "Grandma doesn't do stuff online, but subscribes to a service that prints and sends her photos. Peter wants to give printing/sending access rights to the service." You, as the photo owner, may want to commit the printing service not to use or further share the photos beyond this task, and may want to audit their periodic retrievals of photos for printing and mailing.
- Using a service that creates photo thumbnails and other reduced-size versions
In this case, you are giving "read" access to your photos, but also "write" access to hold the results of the processing. This is perhaps similar to the way some OAuth-connected location services can either read your location from, or write your location to, each other.
| Anchor | ||||
|---|---|---|---|---|
|
Submitted by: participant-name
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: participant-name
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
| Anchor | ||||
|---|---|---|---|---|
|
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.)
...
| Anchor | ||||
|---|---|---|---|---|
|
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, photo set 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".
With respect to service access to photo sets, today's OAuth usage is instructive. Every OAuth service provider has the opportunity to offer unique and interesting policies that relate specifically to its connection with certain other applications. It might be the case that some policies simply can't be externalized into an authorization manager, or that greater communication between service providers and authorization managers need a wider and more frequent communication path so that users can apply even SP-specific settings while visiting their relationship manager.
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.
| Anchor | ||||
|---|---|---|---|---|
|
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.)
| Anchor | ||||
|---|---|---|---|---|
|
Related to: calendar scenario, photo set 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.
| Anchor | ||||
|---|---|---|---|---|
|
Related to: calendar scenario, photo set 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.
It may be necessary for us to consider "partial measures" in the V1 UMA effort to improve adoption. Some such measures are: terms that can be passively accepted ("I Agree") rather than terms that require positive demonstration of intent (such as payment receipts); policies that don't require explicit agreement on the part of the recipient but are somehow attached to the data supplied ("sticky policies"); and policies about which the recipient is merely informed rather than asked to agree with.
...
| Anchor | ||||
|---|---|---|---|---|
|
...