...
- 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 necessaryhave better options for recourse.
- ...and she wants to be able to cut off their future access to information about her.
...
- How can we ensure that the sensitive data is secured at rest (in the RM) and in motion (while being conveyed to Staplers)?
- What is the right 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?
Use Case: Payment-Privacy-Enhanced Online Purchase (Pending)
Submitted by: Eve Maler
In this variant, the site from which Maya wants to buy a shredder doesn't make her supply a credit card number; instead, it's prepared to accept payments through payment service MoneyBuddy, with which Maya happens to have an account. To start with, Maya has already stored, and packaged together, the set of relevant data:
- An OAuth token that will let the recipient send MoneyBuddy a legitimate request for payment from Maya's account (??)
- Her shipping address and phone number
So...
- 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 and the policies she expects it to adhere to in accepting her information (they have to ask her, real-time, for permission to get any particular payment through MoneyBuddy, 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 MoneyBuddy OAuth tokens, 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.
Issues
- 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)
...
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).
Issues
- What about shipping schedules and warranty periods? The vendor must retain the possibility of communicating with Maya for some period of time after the moment of purchase. Could we use OAuth tokens in combination wtih an interaction service endpoint to let the vendor communicate with Maya in future while keeping her (more) anonymous?