...
Issue: Policies Specific to the Web Resource Type
Related to: calendar scenario, location 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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Related to: calendar scenario, location 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 Hosts 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, location 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.
...
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, location scenario
...
How Terms can be Met
An AM has two major tools at its disposal in allowing access to a user's resources: policies declared by the authorizing user, and terms which the Requester must meet in order to gain access. To a first approximation, policies can be unilaterally applied, whereas terms require two parties to come to agreement.
Because policies are anticipated to be applied by an AM "silently" (out of band) with respect to the UMA protocol, this is an opportunity for AM business value and we should not dictate any answers here. But following are some policies that could be useful:
- How long to allow access: once, some number of times, for some period, indefinitely until the user says to stop, etc.
- Whether to let the user exercise a "right of refusal" by some interactive means (such as SMS) when a Requester approaches a particular resource: every time for that Requester, only the first time for that Requester, every time for every Requester, etc.
By contrast, terms might take some of the following forms:
- Make the Requester promise not to sell or otherwise commercially use the data thus acquired (in Creative Commons-like fashion)
- Require the Requester to pay the user ten dollars
The following hypothetical wireframe (with hypothetical Creative Commons-like sets of standard terms) imagines what a user interface could look like for an AM's default policy and term settings for all resources it manages:
The UMA group is hoping to borrow from the work of others in using any standard sets of terms that might exist, for example as might be developed by the Kantara Information Sharing (UD-VPI) WG. However, even if this area is well fleshed out, major design questions remain.
Human interaction by a party "behind" the Requester
Some parties behind a Requester's actions may be big companies like credit card issuers, large e-commerce sites, or government agencies – but some may be small organizations, such as a dentist's office. Small organizations may need a human-accessible interface and the option of an "I Agree" button so that the person manually fielding Alice's an offer of data can complete the transaction.
Requester resistance to user-driven terms
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. For example, it may be more difficult to demand evidence of positive action (such as payment) from a Requester vs. demanding a simple statement of passive acceptance of terms (such as "I agree not to sell the data"). This would be a natural first step if Requesters are at all amenable to the notion of user-driven terms.
If we discover that Requesters are resistent, we may need to consider options for allowing the user to passively inform the Requester of policies such as "I ask you not to sell this data", rather than requiring action on the part of the Requester to accept such terms. Or given that Requesters are today in the habit of making their own terms of service and privacy policies known to users in passive fashion, we may need to account for a case where the user's terms amount to an opening gambit of "What can you offer me?" in a contract negotiation.
Depth of contract negotiation
There is some minimum functionality needed around a sequence roughly like the following:
- AM presents terms based on user configuration of same, followed by...
- ...Requester demonstrates that it meets the terms presented
However, there are many layers of sophistication we could get into, depending on where our scenarios take us. For example, is it important for the user to be able to specify "you must satisfy these terms 'or better'"? If so, what does "better" mean? Do we have to solve for "I will sell you n pieces of data for terms X, but n+m pieces for terms Y"?
Legal enforceability and terms persistence
We have discussed whether machine readability of terms is strictly needed, since having a URL that persistently refers to a human/lawyer-readable version seems to suffice in a lot of cases today for string-matched satisfaction (no complex negotiation), including very complex enterprise cases. Nat Sakimura's blog post on contract exchange suggests various ways to characterize, share, negotiate, and record data-sharing contracts. How we answer these questions also has an impact on our goals around simplicity, particularly our emerging goal around not adding undue cryptography burdens.
Paul Bryan has stated a preference expressing a set of terms as a Web resource whose representation can be retrieved with an HTTP GET and modified (with an affirmation that the terms are being met) with an HTTP POST.
...
| Anchor | ||||
|---|---|---|---|---|
|
...