This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments.
Intellectual Property Notice
The User-Managed Access Work Group operates under Option Liberty and the publication of this document is governed by the policies outlined in this option.
Table of Contents
Introduction and Instructions
This document is a product of the User-Managed Access Work Group. It records the scenarios and use cases governing the development of the User-Managed Access protocol and guiding associated implementations and deployments, and outlines technical issues raised thereby.
Please use the scenario template near the end of this document in adding new scenarios and subordinate use cases. Change the status keyword in each scenario and use case title as appropriate, linking to the meeting minutes page explaining the status change:
- 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 (Accepted)
Submitted by: Eve Maler
Online calendars are an example of personal data that is readily shared with other people in a manner that evokes VRM paradigms. Because calendar data is fairly volatile, static calendar snapshots are rarely shared; rather, a calendar feed is provided and authorized recipients can pull fresh calendar data as required. The data is often considered sensitive and is expected to be kept secure, hence "private URLs" and (minimal) ACL features offered by Google Calendar and other hosts.
In this scenario, personal online calendars are shared with "vendors" (online services) rather than other individuals, and they are shared in such a way as to allow permissioning and auditing from a central location rather than wherever the calendar is hosted. For the purposes of this scenario we'll focus on sharing a single online calendar (such as for "work", "soccer", or "travel") as a unitary Web resource, on an ongoing basis, with one or more individually-authorized recipients.
User interface mockups of a calendar-sharing interaction can be found in the initial blog post made about ProtectServe and, in somewhat more sophisticated form, slides from a speech made at an identity conference.
Following are some motivating circumstances in which calendar-sharing with vendors may make sense. (NOTE: All references to real vendors are hypothetical.)
Travel Calendar Sharing with Vendors
Alice, who is based in the Seattle area, has an online calendar that specifically contains business travel details such as flights, hotel stays, and car rentals, and since she travels quite frequently and often to international destinations, she wishes to share it with the following vendors:
- Her Visa credit-card company, Chase
Often when she tries to charge European hotel stays to her Chase Visa, the credit card company denies the charges or asks the hotel desk clerk to put her on the phone to make sure it's really her flitting around Europe and racking up big hotel bills. To let Chase know ahead of time what her travel plans are, Alice decides to share her travel calendar with them on a long-term basis so they can know ahead of time that it's likely truly Alice who's putting a Barcelona hotel stay on the card.
Note that this recipient of her data already has a lot of quite personal and sensitive information about Alice, so she's fairly comfortable giving them access to this data under certain conditions, such as refusing to accept third-party direct marketing.
It must be possible for Alice to cut off the flow of travel calendar data to Chase (even though she continues to use that card for personal purchases) when Alice is told that she has to begin using a corporate AmEx card for all business travel purchases.
- 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 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 mobile carrier, T-Mobile
Alice would like to be offered the option to purchase pre-paid roaming minutes when she travels overseas. By sharing her travel calendar, she can let T-Mobile know that she'll be in Brazil next month and would welcome a special offer on mobile roaming. (Note that this use case has an element of volunteered personal information to it; by positively choosing to share her information, Alice gets new opportunities to transact with vendors.)
- 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.
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 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 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 send her an event invitation for a repair slot.
- 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. 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.
Use Case: Separate Resource Host, Relationship Manager, and Recipient (Accepted)
Submitted by: Eve Maler
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 read 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.
Scenario: Packaging Resources for E-Commerce Vendors (Accepted)
Submitted by: Eve Maler
This scenario focuses on the typical set of information that we hand over to online vendors repeatedly, and the desire to avoid sharing the data "by value", instead focusing on how to share it "by reference" (pointers).
Let's look at how an online buying scenario might look today.
- Bricks and mortar
Maya recently became extra-concerned about identity theft and fraud because a friend had his bank account stolen from, and she has decided to buy a shredder so she can dispose of old bills, credit-card offer junk mail, and outdated backup CDROMs. She visits her local Staplers store, prepared to buy a shredder that day (with cash! hey, it's anonymous), but can't find a shredder in stock that handles CD shredding.
- Comparison shopping
She goes to Google and a couple of specialized comparison-shopping sites and plugs in search terms like paper shredder cdrom, but can't easily figure out which ones have the features she wants, but the prices at Staplers.com, the site for the local store she was just in, look good and she decides to just go ahead and shop there.
- Clicks and mortar
Once Maya is at Staplers.com, she finds a suitable shredder and adds it to her shopping cart (which is, so far, "anonymous" with respect to everything but some sort of device identification, possibly based on a cookie, associated with her browser session).
Following are some key questions we can ask, identified by whether they capture an identity management (IdM) issue, a vendor relationship management (VRM) issue, or a social networking issue. (Note that some of these questions highlight scenarios and use cases that the calendar scenario has already captured. Some of these might want to get turned into unique use cases for this scenario.)
- Can we imagine better ways for Maya to set up a data-sharing relationship with Staplers.com? (IdM, VRM)
- She's planning to move in a couple of months, and that means the address information Staplers has saved will go stale.
- Same for her credit card: it will expire next year. When these items change, she has to go fix them at dozens of sites.
- She's not crazy about having to supply things like credit card information to every vendor on the web.
- Is it possible for Maya to have a "one-night stand" with Staplers.com rather than a long-running relationship? (IdM, VRM)
- ...if she doesn't really want Staplers to track her purchases, browsing habits, or anything else over time.
- ...if she wants to share only the minimum personal information Staplers really needs to do its job this once, and then only temporarily.
- Can we imagine betters ways for Maya to engage in the shopping-around process, possibly involving her sharing more data about herself? (VRM – particularly volunteered personal information!)
- What if she could "issue a personal RFP" indicating the price and features she's interested in, and entertain vendor site "bids", such that not only Staplers.com and OfficeArmory.com could bid, but also Ann, who has a used shredder she'd like to sell?
- What if she could let Staplers know her customer-support phone line preferences, such as wait time and ad-playing tolerance?
- What would it look like for Maya to get a unified understanding of all of her data-sharing relationships? (VRM)
- She sure would like to get a handle on her own "personal data analytics" – "who knows what" about her.
- If Staplers behaves badly (gives out her data against her rules or allows a data breach to occur), she wants to have better options for recourse.
- ...and she wants to be able to cut off their future access to information about her.
Maya shares the information about herself that Staplers.com needs at the beginning of her e-commerce relationship with them, but instead of having to share it "by value", she shares it as some form of pointer to a package of resource pointers that Staplers can dereference and refresh as they needs to over time. She can change the underlying information whenever she wants to without worrying about paying special attention to Staplers (or any of the other hundred e-commerce sites with which she has registered.
- Maya (User)
- Authorization manager (AM)
- Personal datastore (Host) in which authoritative versions of resources to be shared reside (that colocation of AM and Host is not a requirement, but for this scenario the individual resources are assumed to live on a single Host)
- Staplers.com (Requester)
- User can package and reuse pointers to resources commonly needed for e-commerce into a rolled-up resource that is available for access by multiple requesters (assume for this scenario that all the individual resources and the rolled-up resource are available from the same host in the "personal datastore" model).
- The data involved is "self-asserted" to a first approximation. (The credit card data we often share today is "asserted" solely by us, but then the vendor validates it out of band.)
- Requester can handle receiving and dereferencing both a pointer to a package resource and pointers to individual resources.
- AM can manage the offering and meeting of terms for resource-sharing for the whole package and can take advantage of efficiencies where the terms for individual resources are identical (possibly similar to the Distributed Services scenario).
- Requester will often represent a requesting party who is the same human being as the authorizing user, and can take advantage of efficiencies in any real-time requester/AM/user connection for obtaining user consent in that moment.
- Requester, host, and AM are likely to be willing to deal with each other solely on the basis of the user's say-so (unlike in the personal loan scenario).
Use Case: Online Purchase with Setup of a Long-Running Account Relationship (Accepted)
Submitted by: Eve Maler
Preconditions: Maya has already stored, and packaged together, pointers to the set of relevant resources frequently needed for online purchases:
- Her desired credit card number, expiration month and year, security code, name on card, and billing address
- Her shipping address and phone number
- She goes to Staplers.com and puts her desired shredder in her shopping cart.
- When she goes to check out, she's presented with a requirement to register for an account. The form has fields for the data listed above, but also has a new field for "Personal data feed".
- In a separate browser window, Maya visits her Relationship Manager and generates a unique URL representing the disclosure package she wants to offer Staplers (CC number etc.) and the policies she expects it to adhere to in accepting her information (they can't sell her data etc.).
- She goes back to Staplers and pastes the URL she just generated, and presses a button that says "Share personal data".
- The Staplers web application follows the link, discovers it has to agree to a set of policies before getting through to the info it needs, decides to agree, and gets through.
- Staplers retrieves data items with content-types that indicate they contain CC numbers, addresses, etc., and then displays the values retrieved in the regular registration form fields, possibly with some graphical indication that Maya can override any one of them.
- (later) Maya can use her RM to view the activity related to Staplers' retrieval of her information, check what she's told them (and others), and also check the conditions under which she released information.
- How can we ensure that the sensitive data is secured in motion (while being conveyed to Staplers)? (generic across all scenarios)
- What is the right UX paradigm for letting Maya override information? Ideally, any info that's changed should be updated in the RM, not on the Staplers site. But if she wants to override a value just once, with values to be updated in future pulls of the feed, the right place to change it is on the Staplers site itself. Does this latter situation sound likely?
- What about interfaces where the credit card information is provided at a separate point in the process? How should that be accounted for? Perhaps, except for subscription-type payments (ongoing over time), this information is not part of the registration bundle and is provided (by reference or by value) only at purchase time.
Use Case: Engaging in a Purchase "One-Night Stand" (Accepted)
Submitted by: Eve Maler
This is the same as the first use case outlined above, except that Maya provides her resource package not as part of a request to register a new account, but as part of a one-time purchase. (Some websites today allow for purchases without registering, and are prepared not to give you a browser cookie or retain your information beyond necessary for the purchase and its aftermath.)
The policies Maya chooses in this case are likelier to be more stringent about not retaining personally identifiable information (PII) for any significant length of time, and may ask the vendor to generate "positive" assurance messages about policy adherence (not just silent adherence).
(The protected-inbox scenario might play an especially important role if Maya is engaging in a one-night stand purchase, since it enables the vendor to report product recalls and such to Maya without her having to expose other more compromisable communications endpoints such as persistent email addresses or phone numbers.)
Scenario: Granting Service Access to a Photo Set (Pending)
Submitted by: Eve Maler
Today, many Web 2.0 services are beginning to offer users features that depend on connections with other third-party services, using OAuth to forge the connection. A classic example is configuring your photo-hosting site to use some other photo-printing site to print your photos. Whereas the Sharing a Calendar with Vendors scenario primarily focuses on sharing data whose "substance" (your calendar entries) vendors then "consume" to give you interesting service, this scenario primarily focuses on granting service access to other services in order to get combinatorial effects from the service features themselves.
In this scenario, access to photos is shared with other services that can do interesting things with them, in such a way as to allow permissioning and auditing from a central location rather than wherever the photos are hosted. Since it is just as likely that multiple photos might want to be subjected to this treatment as a single photo would be, we'll assume a set of them. Each third-party service is intended to be granted access separately, on possibly unique terms.
This scenario is a bit similar to the Sharing a Calendar with Vendors circumstance in which calendars are shared with Dopplr and TripIt.
Following are some motivating circumstances in which photo access may make sense. (NOTE: All references to real vendors are hypothetical.)
- Making a feed or stream of photos available for printing and mailing to a recipient
This situation is based on that described in item #8 (alternative) of the photo-sharing scenario from the IIW8 Use Case Selection and Metrics session in May 2009: "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." You, as the photo owner, may want to commit the printing service not to use or further share the photos beyond this task, and may want to audit their periodic retrievals of photos for printing and mailing.
- Using a service that creates photo thumbnails and other reduced-size versions
In this case, you are giving "read" access to your photos, but also "write" access to hold the results of the processing. This is perhaps similar to the way some OAuth-connected location services can either read your location from, or write your location to, each other.
Use Case: Consumer Uses Complex API to Interact with SP (Pending)
Submitted by: participant-name
The generic configuration involves a consumer interacting with a separately hosted service provider in some intelligent way based on the SP's capabilities and expectations. This configuration is illustrated below.
Scenario: Distributed Social Networks (Pending)
Submitted by: Christian Scholz
If you look at the social networking scene today one thing is obvious already: There is lot of data online on various services
and much of this data is redundant because it is available in various copies which are usually not synced. The main area
for this problem is probably profile and friendship/contact information. On each social network or service you register
you usually have to enter your profile information again and try to find your contacts.
With the advent of more and more of such social services the amount of redundant data will grow even more and this will lead
to a acceptance problem.
The Service Catalogue idea
It is unlikely that users will centralize all their data in one place. It's more likely that data will be distributed even more.
So one problem might already be to manage all the places where data is stored about you or where services can provide
functionality on your behalf. One solution to this might be a concept called "Service Catalogue" which came up in discussions
in the open web/DiSo/DataPortability communities. The basic idea is to have a list of all these places stored under your
control which can be queried by services.
Another point is that for reducing the amount of copies of your data it is necessary to link to your data instead of copying
it (or even worse asking the user to type it in again). The Service Catalogue can serve basically as such a link list where
each service/type of data is marked up with a location (URI) and type (probably another URI). Obvious things to link to
are your profile and contact list but other things make also sense, like photos, videos, blog posts, recommendations, your
attention profile, travel information and much more.
Now if you want to use a new service you do not even need to "register" but you simply authenticate with it (e.g. with
your OpenID) and point it to the location of your Service Catalogue.
The problem is of course how you authorize that new service to get access to all the other 3rd party services.
OAuth is one possible solution but at least if the default mechanism for retrieving a token is used this means that the user
has to be redirected to each of these 3rd party services in order to give consent for the new service to use that data.
Moreover OAuth does not contain a mechanism to define what permissions are given exactly. One can imagine that for some
services you want to give out your full profile and for others maybe just your name. Moreover this might not only apply to the
service level but also to the user level. E.g. you might want to give a contact tagged "superfriend" your full profile while
for somebody tagged "no idea how he landed on my contact list" you only want to give out basic data.
For the sake of usability what we need is a single page where you can define the relationships between that new service
and all the other services in your Service Catalogue. Moreover it would be helpful to have certain profiles stored to
quickly assign one to this new service.
Possible use cases
Here is a list of use cases which come to mind:
- User logs in to a new service and authorizes 3rd party services
- User adds a new 3rd party service to the Service Catalogue
- User changes the permissions for a service
- User manages permission profiles
Scenario: unique-title (Pending)
Submitted by: participant-name
(Provide description of the scenario with all nontechnical particulars, noting requirements, constraints, and other observations. Avoid diagrams.)
Use Case: unique-title (Pending)
Submitted by: participant-name
(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.)
Following are discussions of technical issues raised by one or more scenarios and use cases. Acceptance of a scenario or use case will imply agreeing to develop a satisfactory solution to applicable issues.
Issue: Policies Specific to the Web Resource Type
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.
With respect to calendar resources, 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. It feels like it should be out of scope 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). An "identity oracle" approach (filtering the data into a completely different type) might be necessary if what Alice is trying to convey is simply "don't deliver my newspaper on these days" vs. "here's all of my travel information".
With respect to service access to photo sets, today's OAuth usage is instructive. Every OAuth service provider has the opportunity to offer unique and interesting policies that relate specifically to its connection with certain other applications. It might be the case that some policies simply can't be externalized into an authorization manager, or that greater communication between service providers and authorization managers need a wider and more frequent communication path so that users can apply even SP-specific settings while visiting their relationship manager.
Some data-usage policies and terms may possibly have an interaction with some resource types, such as requiring recipients to discard volatile data after a period dictated by the data's type.
It has been observed 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 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 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.)
Issue: Handling the Resource URL and Provisioning It to the Consumer Site
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.
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.
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.
Issue: Processes By Which Consumers Meet the User's Data-Sharing Terms
Some of the vendors mentioned in the calendar scenario are big companies; can standard (and machine-readable) data-sharing contract terms 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.
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.
|Current Version (v. 16)||Sep 01, 2009 18:06||Eve Maler|
|v. 60||Oct 05, 2010 22:08||
Migration of unmigrated content due to installation of a new plugin
|v. 59||Oct 05, 2010 22:08||
Migration of unmigrated content due to installation of a new plugin
|v. 58||Oct 05, 2010 22:08||
Migration of unmigrated content due to installation of a new plugin
|v. 57||Oct 05, 2010 22:08||
Migrated to Confluence 4.0
|v. 56||Oct 05, 2010 22:08||
Filled in some links to specific scenarios in examples of dimensions.
|v. 55||Sep 30, 2010 12:44||Thomas Hardjono|
|v. 54||Sep 30, 2010 12:41||Thomas Hardjono|
|v. 53||Sep 30, 2010 12:34||Thomas Hardjono|
|v. 52||Sep 30, 2010 12:28||Thomas Hardjono|
|v. 51||Sep 30, 2010 12:25||Thomas Hardjono|
|v. 50||Sep 30, 2010 12:14||Thomas Hardjono|
|v. 49||Sep 22, 2010 10:56||Thomas Hardjono|
|v. 48||Sep 20, 2010 16:43||Thomas Hardjono|
|v. 47||Sep 20, 2010 16:42||Thomas Hardjono|
|v. 46||Sep 20, 2010 16:40||Thomas Hardjono|
|v. 45||Sep 20, 2010 16:19||Thomas Hardjono|
|v. 44||Sep 20, 2010 16:11||Thomas Hardjono|
|v. 43||Feb 16, 2010 10:35||Eve Maler|
|v. 42||Feb 16, 2010 10:29||
Added "Hey, Sailor" (advertising a resource) scenario
|v. 41||Jan 28, 2010 19:35||Eve Maler|
|v. 40||Jan 25, 2010 00:20||Eve Maler|
|v. 39||Jan 24, 2010 10:03||Maciej Machulak|
|v. 38||Jan 13, 2010 12:44||
Broke out the terms negotiation scenarios into a new top-level section
|v. 37||Jan 09, 2010 18:16||Eve Maler|
|v. 36||Jan 09, 2010 18:07||Eve Maler|
|v. 35||Jan 09, 2010 18:05||
Revised editors, put generic issues into its own file
|v. 34||Dec 16, 2009 17:48||Hasan|
|v. 33||Dec 16, 2009 17:43||Hasan|
|v. 32||Dec 16, 2009 17:41||Hasan|
|v. 31||Dec 04, 2009 17:32||Eve Maler|
|v. 30||Dec 04, 2009 15:38||Eve Maler|
|v. 29||Dec 04, 2009 15:33||Eve Maler|
|v. 28||Dec 03, 2009 11:18||Maciej Machulak|
|v. 27||Nov 21, 2009 10:17||Eve Maler|
|v. 26||Oct 08, 2009 19:11||
Added reference to module for Requester Delegate scenario
|v. 25||Oct 04, 2009 20:16||
Took out "related to" links from Issues to specific scenarios; expanded the Issue related to "terms"; revised to use new terminology
|v. 24||Sep 18, 2009 06:34||Eve Maler|
|v. 23||Sep 18, 2009 05:47||Eve Maler|
|v. 22||Sep 18, 2009 05:14||Eve Maler|
|v. 21||Sep 08, 2009 14:00||Domenico Catalano|
|v. 20||Sep 07, 2009 09:50||
replaced old version of distributed social networking scenario with new one about distributed services (and used inclusion)
|v. 19||Sep 06, 2009 22:43||Eve Maler|
|v. 18||Sep 06, 2009 22:38||Eve Maler|
|v. 17||Sep 06, 2009 22:28||Eve Maler|
|v. 16||Sep 01, 2009 18:06||Eve Maler|
|v. 15||Sep 01, 2009 14:23||Hasan|
|v. 14||Sep 01, 2009 14:19||Hasan|
|v. 13||Aug 13, 2009 05:42||
added new scenario about Distributed Social Networks
|v. 12||Aug 11, 2009 21:30||
This and all previous revs are "editors' drafts" and have not been approved by the group
|v. 11||Jul 25, 2009 16:29||Eve Maler|
|v. 10||Jul 25, 2009 09:51||Eve Maler|
|v. 9||Jul 23, 2009 18:08||Eve Maler|
|v. 8||Jul 23, 2009 16:43||Eve Maler|
|v. 7||Jul 23, 2009 16:34||Eve Maler|
|v. 6||Jul 23, 2009 16:30||Eve Maler|
|v. 5||Jul 23, 2009 15:14||Eve Maler|
|v. 4||Jul 23, 2009 13:55||Eve Maler|
|v. 3||Jul 23, 2009 13:33||Eve Maler|
|v. 2||Jul 23, 2009 13:31||Eve Maler|
|v. 1||Jul 23, 2009 12:53||Eve Maler|