...
- 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 (by filling out a web form or using the phone), so she already had to trust the service not to rob her house while she's away. It's likely her full travel calendar contains more data than the service strictly needs, however.
- The U.S. Postal Service
Instead of having to go to the Post Office or its website to fill in out 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 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. (See the forthcoming scenario Granting Service Access to a Photo Set for more observations on this flavor of scenario.)
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 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:
...
- 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 the MA 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 Alice 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.
...
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 SPs 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.)
...
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.)
...
| Anchor | ||||
|---|---|---|---|---|
|
...
(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.)
...