...
| Table of Contents | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
Introduction and Instructions
...
- 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)
...
- 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 send her an event invitation for a repair time with herslot.
- 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.
...
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 unique content - type characteristics.
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).
...
| 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.)
...
| Anchor | ||||
|---|---|---|---|---|
|
...