Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Requires a packaging of several resources, and repeated use of that package with different recipients.
  • The data involved is "self-asserted" to a first approximation. For example, the credit card data we often share today is "asserted" solely by us, but then the vendor validates it out of band.
Problem scenario

Let's look at how an online buying scenario might look today.1.

  1. 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.

...

  1. 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.

...

  1. 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 the IP address associated with her browser session).

...

  1. Checkout

    When she goes to check out, Maya is asked for consent and personal data for various purposes. First, she must choose a username and password, on the theory that this will make her future purchases at the site easier. She also has to provide her home address and phone number (though this isn't so onerous because her browser auto-fills the data) so Staplers can transfer the shredder to its outsourced shipping company for delivery, and her credit card number, its security code, its expiration date, and her real name (the name the card was issued to) so Staplers can be paid for the purchase. Finally, she is asked to click "I Agree" certifying that she agrees to Stapler's site terms of use and has seen its privacy policy.
Desired improvements

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.
    • She thought the site terms and privacy policy were just "okay", but accepted them because she effectively has no choice – and OfficeArmory.com is probably the same anyway.
  • 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 UD-VPI!)
    • 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 be able to prove so – in court, if necessary.
    • ...and she wants to be able to cut off their future access to information about her.
Solution Scenario

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 a 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.

Actors:

  • 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)

Distinctive aspects:

  • User can package and reuse resources commonly needed for e-commerce into a rolled-up resource
  • 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 (might this be similar to the Distributed Services scenario?)

Use Case: Online Purchase with Setup of a Long-Running Account Relationship (Pending)

...

  • Does the OAuth token idea make sense? It inverts the usual order of introducing two of your applications to each other. Is this detail too specific for the use case or should we leave it in?

Use Case: Engaging in a Purchase "One-Night Stand" (Pending)

...