Use Case Selection and Metrics

Conference IIW8 Room/Time: 9/A

Convener: Eve M and Alan K

Notes-taker:

Attendees:

Technology Discussed/Considered:

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

Alan presented an example from the physical world that demonstrates the following aspects of sharing that we should seek to emulate in the online world:

• Dynamic (no pre-setup to enable sharing)
• Chained
• Cross-domain
• Composable (merging rights and sharing from multiple sources)
• Attenuated (rights can be strictly subsetted as you go along)
• Accountable

He proposes selecting one or two use cases and explore them in depth to see if they have the characteristics we're all seeking.

We had a short discussion about how hard it is to separate metrics for use cases from metrics for solutions to the use cases.

Eve proposes that we need dynamicism of this sort: A user can choose to publish a URL that a potential data recipient can attempt to retrieve against, where the recipient didn't have to take any steps prior to the initial GET attempt and where the attempt doesn't necessarily result in a successful retrieval.

Peter Davis proposes a specific use case involving wanting to share an album of event (e.g. camping) photos, the subjects of which are minor children, with exactly the set of dads whose kids are in the pictures, without exposing the pictures to anyone else. Trent proposes a variant where the photographer is a professional who has to get signed release forms, such that the list of people with whom you want to show the photos is known. For someone to print a photo, you need to share the photo with them.

Many services do photo sharing today by emailing special URLs to give people (who are not otherwise known to the photo service) to get access to the data.

Eve proposes that a use case metric we should adopt is that keeping the URL secret should not be relied on for the security of the overall system. We started calling this a "suckiness" factor. :-) Peter is going to have to solve this for his camping photos by explicitly constructing a photo-sharing Facebook group for this event that names the people explicitly! Alan then proposes ease-of-permissioning as a solution metric -- "pain-in-the-assiness". :-)

Bill Smith had described the enterprise outsourcing use case on Monday; some companies, especially really small ones, often outsource everything. Peter elaborates: five guys get into a room and declare they're part of a company. Now you have to control access to all sorts of resources (sharing documents, authorizing bill payments, etc.).

Peter describes an enterprise use case where the entire company collaboratively serves in a policy-making function. Any employee can contribute a product idea, and if a really good one arises, people can decide that it needs to be subsequently restricted from the view of the entire company, to protect it.

Asa described managing entreprenurial discussions with reputation systems (a discussion that took place at the Berkman Center).

The separation of policy decision-making and policy enforcement is important.

There's a database that relies on trusted experts to indicate who is the author of a book, the heir of an author, etc. An author might want to have an agent operating on their behalf asserting the author's rights in the work. The trusted experts perform, in effect, identity proofing.

Revocation of various sorts came up. Peter may want to deprovision the rights of a particular person to access photos, including destroying their cache of photos! And Alan points out that if Wikipedia wants to revoke a "bad" editor's rights, it also might want to roll back any content the person had contributed.

10:15am hour:

We walked through the photo-sharing use case in detail:

Assumptions:

• There is at least one parent on the camping trip who doesn't want photos of their kids put online.

• The person who took the photos can always view photos of their own kid.

• The online photos in question are referenceable individually and in a collection.

• People who want to use a photo you took need to seek your permission to use it, print it, etc.

1. Peter goes on a camping trip, taking photos as he goes.

2. He meets or knows most, but not all, of the other participants in the trip. And some situations involve total strangers (others at the swimming hole that day). Photojournalists takes pictures and then immediately seeks releases.

3. He returns home and publishes a set of photos from the trip, initially to himself.

4. He shares access to the photos with a selection of people, including the parents of the photo subjects, who can then themselves share access to selections of other people.

5. One of the other parents, who had taken their own photos during the trip, wants to add those photos to the set, with all the data-sharing properties you have set up for the photo set as a whole.

6. Grandma, with whom two different parents (her son, Peter, and her daughter) have shared separate photos of their kids, wants to "mash up" the photos into a composite such as an online scrapbook page.

7. Grandma wants to share her scrapbook page, which contains two different photos that have different data-sharing rules attached to them, with her bridge club.

8. One of the other parents is a professional photographer and takes advantage of his Creative Commons copyright license grant to create derivative works to crop and edit the photo. Later, when his kid leaves the troop, you want to revoke his rights to the photo set.

Alternative scenario: 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. (This gets at the VRM individual-to-service data-sharing use cases.)

Having built the use case and its variant, we discussed what metrics any solutions could be measured on. Here's a composite list of the ones we've discussed to date:

• Dynamic (no pre-setup to enable sharing)
• Chained
• Cross-domain
• Composable (merging rights and sharing from multiple sources)
• Attenuated (rights can be strictly subsetted as you go along)
• Accountable
• Usable
• "Security" (practical ability to control access to the desired people)
• The "oops factor" (when security can be accidentally compromised even by sophisticated users -- related to security+usability)

There's a bunch more, largely obvious, that we didn't have time to list.

We discussed reserving the word "suckiness" for the ability (actually the lack thereof) of a particular solution to meet a metric, rather than one of the metrics itself. :-)

Alan suggests that URLs should be used as rights-carrrying objects; several others objected because URLs were designed precisely to "give directions" for where to get a resource.

We ran out of time to review various existing and proposed solutions against the various metrics. This is an exercise that can be done offline (perhaps on the community@lists.idcommons.net list?).