Difference between revisions of "Identity issues"

From Project VRM
Jump to navigation Jump to search
m
Line 4: Line 4:
  
 
In light of Don Marti's elegant Upside-down buyer's guide idea (currently living in [[Project ideas]]),  publicly verifiable vendor identity goes from a nice-to-have to a virtual requirement.  While it doesn't seem to make sense for seeker identity, does a DNS-overload approach (think Domain Keys or SPF) make sense as a partial mechanism for establishing vendor ID?  If so, does that automatically disallow third parties that don't have Web presence/commerce of their own?
 
In light of Don Marti's elegant Upside-down buyer's guide idea (currently living in [[Project ideas]]),  publicly verifiable vendor identity goes from a nice-to-have to a virtual requirement.  While it doesn't seem to make sense for seeker identity, does a DNS-overload approach (think Domain Keys or SPF) make sense as a partial mechanism for establishing vendor ID?  If so, does that automatically disallow third parties that don't have Web presence/commerce of their own?
 +
 +
Note possibility of reputation coming into play here: reliable identity is key if the repuation/trustworthiness of a vendor (or another seeker, as a source of information about a vendor) is a factor in offer evaluation...and it seems like it should be, at some point.  Very nice extension of the idea.

Revision as of 01:53, 21 December 2006

Very much a stub...

For VRM to work, there's a minimum requirement of a GUID for each seeker. For reasons outlined in the privacy issues section, I don't believe that seekers' RFPs should contain contact information. In this context a GUID could be as simple as as public URL; (And yes, I'd really like to come up with a better term than "seeker," but nothing's yet come to mind.)

In light of Don Marti's elegant Upside-down buyer's guide idea (currently living in Project ideas), publicly verifiable vendor identity goes from a nice-to-have to a virtual requirement. While it doesn't seem to make sense for seeker identity, does a DNS-overload approach (think Domain Keys or SPF) make sense as a partial mechanism for establishing vendor ID? If so, does that automatically disallow third parties that don't have Web presence/commerce of their own?

Note possibility of reputation coming into play here: reliable identity is key if the repuation/trustworthiness of a vendor (or another seeker, as a source of information about a vendor) is a factor in offer evaluation...and it seems like it should be, at some point. Very nice extension of the idea.