Identity issues: Difference between revisions
Whitneymcn (talk | contribs) No edit summary |
Whitneymcn (talk | contribs) No edit summary |
||
| Line 2: | Line 2: | ||
For VRM to work, there's a minimum requirement of a GUID for each <em>seeker</em>. 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.) | For VRM to work, there's a minimum requirement of a GUID for each <em>seeker</em>. 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? | |||
Revision as of 09:18, 19 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?