Standards Committee Teleconference 2008 07 02: Difference between revisions

From Project VRM
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 27: Line 27:


==Notes==
==Notes==
===Gnip===
Interesting. May be useful for personal datastore/data propagation. http://blog.gnipcentral.com
===One Night Stands===
All the power of long term identity-based relationships, but just for NOW, with no strings attached.
Staples.com requires a username/password for purchase, so that return uses are easier.
But that is lame. Why create an identity just so the /return/ is easier?
If we can provision the current fresh data on-the-fly, we'll have /more/ not less relationships, each of which is potentially ephemeral because there's no login-lockin.
Perception: because users have login-lockin, they'll come back more often.
Eve: In the world of paper catalogs, I get sent offers. I can look at them if I want, and typcially will order by phone, instead of online. I tell them what I want... and they ask for the number from the catalog, which is then used to pull up my record in their system. That is easier than going online where you have username/password issues.
Joe: but that's not really a one-night-stand. They've been courting you for a while. They have your address, which you probably gave to them or gave to another catalog company. And once you order, they have long term retention.
But from a user perception, it almost feels like it. Simple, unobtrusive.  In the mail order catalog system, where the buyer calls, they have made it as easy as possible to provision the data record to give the buyer what they want.
We should be able to show up at Staples.com, and in one step, have them automatically get the data they need to make a perfect transaction (my address, billing preferences, etc.). And have that be data-protected, privacy-safe, etc.
Goal: enable a first-time transaction to be just as efficient as a long term relationships.
Side effect: The vendor doesn't have to keep the data.
Requirement: ease of high-level provisioning.
Non-repudiation?
Especially in the one-night-stand case, where people would like prove about data persistence, propagation, etc. Receipts of that sort is a hard problem.  It should be possible to assert a policy requesting an explicit statement/assertion/representation by the vendor that they adhere to my data retention policies.
MySpace is doing this, of a sort, with their Data Availability initiative. That is a blanket TOS for all vendors, across all users.
Formal assertion of de-provisioning of the data.
Perhaps the real challenge is getting the policy agreement in place before users give away all their data. Because once the data release is normal, it will be hard to change vendor and user behavior.
User selected policy.  If we had the PAM in place, we still couldn't use it. It wouldn't matter what policy we assert, because we /still/ have to give Amazon our address.
Users need some sort of agent, acting only on user impulse, on their behalf. That impulse may be provided at policy provision, but was also need to be aware of blanket policies that actually presume an impulse.
===Workshop Planning===
#PAM intro
#PAM working session on One Night Stands
#RelButton standards track work
#Policy stuff (building on Asa's PAM policy work) [optional]
##User-driven verses vendor-specified
##Technical
##Legal
===Future Agenda Topics===
#Discuss the distinctions between a Service Endpoint and a Service Manager.
==Action Items==
==Action Items==


Latest revision as of 13:25, 2 July 2008

Standards Committee Teleconference Call Notes

Drafted by Joe Andrieu, July 2, 2008

Other Calls

Category:Standards Committee Teleconferences

Attendees

  • Joe Andrieu
  • Eve Maler
  • Drummond Reed

Previous Action Items

  1. One Night Stand Use Cases - Eve - Before July 2
  2. Flower Power Scenario Diagrams - Asa - Before July 2
  3. Write up notes from call into wiki - Joe - By Monday
  4. Send blog post seeds to Drummond re: r-cards - Joe - Today
  5. Blog about current state of r-cards - Drummond - Next Week

Agenda

  1. Set Agenda
  2. Review previous Action Items
  3. Gnip anyone?
  4. Discuss the differences between one-night-stands and long term relationships with service providers and vendors.
  5. Planning for VRM Workshop
  6. Review Action Items

Notes

Gnip

Interesting. May be useful for personal datastore/data propagation. http://blog.gnipcentral.com

One Night Stands

All the power of long term identity-based relationships, but just for NOW, with no strings attached.

Staples.com requires a username/password for purchase, so that return uses are easier.

But that is lame. Why create an identity just so the /return/ is easier?

If we can provision the current fresh data on-the-fly, we'll have /more/ not less relationships, each of which is potentially ephemeral because there's no login-lockin.

Perception: because users have login-lockin, they'll come back more often.

Eve: In the world of paper catalogs, I get sent offers. I can look at them if I want, and typcially will order by phone, instead of online. I tell them what I want... and they ask for the number from the catalog, which is then used to pull up my record in their system. That is easier than going online where you have username/password issues.

Joe: but that's not really a one-night-stand. They've been courting you for a while. They have your address, which you probably gave to them or gave to another catalog company. And once you order, they have long term retention.

But from a user perception, it almost feels like it. Simple, unobtrusive. In the mail order catalog system, where the buyer calls, they have made it as easy as possible to provision the data record to give the buyer what they want.

We should be able to show up at Staples.com, and in one step, have them automatically get the data they need to make a perfect transaction (my address, billing preferences, etc.). And have that be data-protected, privacy-safe, etc.

Goal: enable a first-time transaction to be just as efficient as a long term relationships. Side effect: The vendor doesn't have to keep the data.

Requirement: ease of high-level provisioning.

Non-repudiation?

Especially in the one-night-stand case, where people would like prove about data persistence, propagation, etc. Receipts of that sort is a hard problem. It should be possible to assert a policy requesting an explicit statement/assertion/representation by the vendor that they adhere to my data retention policies.

MySpace is doing this, of a sort, with their Data Availability initiative. That is a blanket TOS for all vendors, across all users.

Formal assertion of de-provisioning of the data.

Perhaps the real challenge is getting the policy agreement in place before users give away all their data. Because once the data release is normal, it will be hard to change vendor and user behavior.

User selected policy. If we had the PAM in place, we still couldn't use it. It wouldn't matter what policy we assert, because we /still/ have to give Amazon our address.

Users need some sort of agent, acting only on user impulse, on their behalf. That impulse may be provided at policy provision, but was also need to be aware of blanket policies that actually presume an impulse.

Workshop Planning

  1. PAM intro
  2. PAM working session on One Night Stands
  3. RelButton standards track work
  4. Policy stuff (building on Asa's PAM policy work) [optional]
    1. User-driven verses vendor-specified
    2. Technical
    3. Legal

Future Agenda Topics

  1. Discuss the distinctions between a Service Endpoint and a Service Manager.

Action Items

Next Meeting

Face to face at the VRM 2008 Workshop Standards Committee Teleconference 2008 07 30

Retrieved from "http://cyber.harvard.edu/projectvrm/?title=Standards_Committee_Teleconference_2008_07_02&oldid=2818"