Identity issues: Difference between revisions
Whitneymcn (talk | contribs) No edit summary |
m (Reverted edits by Hiphopalemi (Talk) to last version by Joe.andrieu) |
||
| (6 intermediate revisions by 5 users not shown) | |||
| 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. | |||
Dropping a link in here so that I don't forget: [http://blog.joeandrieu.com/2006/12/03/internet-identity-reputation-networks-and-more/ Andrieu on Reputation Networks and More]. The longer it rolls around in my head, the more significant reputation seems to be in this whole process. | |||
---- | |||
Feel free to edit this part... MikeWarot (Ka9dgx) | |||
VRM can't work without identity. To be clear, I'll use the conventional terms for things... | |||
If I as a consumer want to use VRM to offer the chance to sell to potential vendors, I have to provide a secure channel for getting information back to me. In the CRM world, the Corporate Presence (Website, etc) serve as a defacto means of security the identity of the Vendor, and the means of securing the identity of the consumer is usually by withholding goods or services until some form of payment is tendered, making the identity of the consumer a lower priority for the vendor, because they don't care... they just want to sell and get paid. | |||
In a VRM world, the situation is completely inverted... the consumer knows who they are, and must provide some proof that they are willing to pay... but have no means of verifying the identity (and thus reputation) of a Vendor within the VRM framework... and thus must eventually revert to the CRM model unless some alternative means is provided. | |||
---- | |||
I bring this up because one of the examples I recently suggested was VRM as a tip jar. In order for it to work on a large scale, there has to be some identity proof for the Vendor, even if the consumer doesn't have goods to withhold, because they don't want to pay for fraudulent claims... their money should go to the right person. | |||
Unless there is some form of identity verification both ways, with some mutually trusted party in the middle, VRM is going to face an uphill battle for adoption. | |||
Latest revision as of 12:22, 1 December 2009
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.
Dropping a link in here so that I don't forget: Andrieu on Reputation Networks and More. The longer it rolls around in my head, the more significant reputation seems to be in this whole process.
Feel free to edit this part... MikeWarot (Ka9dgx)
VRM can't work without identity. To be clear, I'll use the conventional terms for things...
If I as a consumer want to use VRM to offer the chance to sell to potential vendors, I have to provide a secure channel for getting information back to me. In the CRM world, the Corporate Presence (Website, etc) serve as a defacto means of security the identity of the Vendor, and the means of securing the identity of the consumer is usually by withholding goods or services until some form of payment is tendered, making the identity of the consumer a lower priority for the vendor, because they don't care... they just want to sell and get paid.
In a VRM world, the situation is completely inverted... the consumer knows who they are, and must provide some proof that they are willing to pay... but have no means of verifying the identity (and thus reputation) of a Vendor within the VRM framework... and thus must eventually revert to the CRM model unless some alternative means is provided.
I bring this up because one of the examples I recently suggested was VRM as a tip jar. In order for it to work on a large scale, there has to be some identity proof for the Vendor, even if the consumer doesn't have goods to withhold, because they don't want to pay for fraudulent claims... their money should go to the right person.
Unless there is some form of identity verification both ways, with some mutually trusted party in the middle, VRM is going to face an uphill battle for adoption.