7C: Use Cases for User-Managed Access

Conference IIW8 Room/Time: 7/C

Convener:

Notes-taker: Eve Maler

Attendees:

Technology Discussed/Considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The following notes provide a long-form description of each of the use-case discussions as they were taking place, followed by an attempt at a short-form summary of the use case identified.

Joe's approach to search: a search map gets created that contains all the context of a search (which may have been built up for months), and that needs to be shared. You can also synchronize that data with yourself on another device. You can also have collaborated synchronization, where multiple users contribute to a single document.

• Single-user, multi-device synchronization
• Multi-user synchronization (future)

Joe wants to identify PII he wants to be merged into data sets, at delivery time, that he provides to others, but that doesn't get used when someone else uses the same search map and its auto-fill feature. A search map contains everything related to your search, and those are used to make social recommendations (by agreement with the user).

• Fields retrieved only at run rime, variable per user, with only a reference to it archived

You're a small business owner who wants to delegate access into your QuickBooks web app to your virtual assistant, such that they can do some subset of your full set of tasks. If they then farm out some of that work, they further constrain (attenuate) the accessible tasks to that other party such that it's a strict subset.

In the VRM context, we also had the "Flower Power" use case: We want to be able to surprise a friend by sending them flowers, which involves you, the friend, the flower shop, and the delivery company.

We believe FedEx does have the option now of providing a shipping label that has only a bar code rather than printing the address for all to see.

The Confused Deputy problem: http://en.wikipedia.org/wiki/Confused_deputy_problem

• Constrainable and attenuatable delegated access

You give someone your shipping address, they hold onto it for a week to ensure the item gets delivered, and you want to revoke their right to use the data after the item is delivered. We think this can be baked into the contract at the beginning, even though the expiration time is variable.

Expiry of rights based on some variable future events

If a company does something you don't like, you may want to change or terminate an agreement. This could happen "eagerly" (proactive revocation by the user) or "lazily" (revocation happens whenever the requesting app happens to check in). Being able to terminate access and usage rights is the moral equivalent of single logout. :-)

• Revocation of access rights, to varying degrees of vehemence

It would be useful to share a limited amount of calendar data, for a limited period, with a doctor's office so you can solicit an event invitation. They themselves may have to coordinate the availability of multiple parties, such as the attending doctor, the MRI machine, etc.

• Soliciting event invitations through sharing calendar data

How do we enumerate the kinds of access available? How does the printing service know how it can request a photo for printing? What are the parameters of the GET? Does WADL help in a RESTful scenario? The consumer using a service gets to see only the parts of the API that it's allowed to use.

• Limited disclosure of service capabilities

We agree that the major proposition here is provisioning recipients with pointers to data rather than provisioning them with the data by value. If the pointer (to, say, an address) is a URL, it's actually harder for a user to provision it "by typing" than it would be for the user to provide the address itself! However, you'd only have to provide it once. :-) But providing it by means of an information card would be very handy.

• Using an infocard to convey resource feeds

Sometimes you want to package up a set of information that's commonly needed by a set of consumer parties, such as your credit card data and a claim saying you're over 25. This could be (but doesn't have to be) an Atom document that serves as a manifest for links to the pieces of data. We discussed the pros and cons of information cards (as they are specified today in ISIP and IMI) for doing this; currently cards are limited to single-issuer claims, but it's an artificial limitation. If your personal datastore pulled down third-party-signed blobs and stored them, you could get the "non-auditing" use case for free!

• Sharing frequently offered data from multiple sources as a package

We may want to ensure that, if search results hit a sufficiently high number, they can be used; otherwise they can't be. This makes sure that data is obfuscatable to at least some degree.

• Constraints on data usage that depend on the nature of the data actually delivered