- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 27 Aug 2011 16:49:45 -0400
- To: public-webpayments@w3.org
>> It would effectively be a ruling that if you >> want to distribute content on the Web, you have to pre-register it at >> a central authority. > > No, I believe your "distribute" is too broad: even if there is a central > registration database, one will only need to do this if they want the > kind of control -- for financial or copyright reasons -- that this > automatic checking can give. People who don't want to use it can > continue as they are today. It would be an opt-in system, with the > owners/creators being the people who register their own works. At this > point I also see no problem with allowing pseudonyms, so whistleblowers > and political activists can still use it, as well as people who just > wish to be anonymous relative to their published works; much like book > publishers do successfully now, and have for centuries, with authors who > wish to remain pseudonymous. Those requirements seem diametrically opposed to one another. How can you have a central authority that is required to check that ownership claims for a particular piece of content is valid /and/ have anonymity at the same time for whistle-blowers and political activists? What this is really boiling down to is the fundamental question of "Who do you trust?" A subset of journalists may trust a particular whistle-blower (WikiLeaks, Anonymous, LulzSec), while others wouldn't. The same for political activists, the same for book publishers. Who we trust is contextual and important, so I do agree that there needs to be some open way of publishing and retrieving the components of one's online identity. We've been impressed with a sub-set of WebID to publish identity (public keys, which are then used to verify digital signatures). WebID Introduction http://vimeo.com/22947088 WebID Demo Blog Post http://digitalbazaar.com/2010/08/07/webid/2/#demo This approach is decentralized by design, but can have a centralized lookup component to provide an optimization. So, in order to tell my software who I trust and who I don't, I can specify an IRI to the identities that I trust and the ones that I don't, like so: https://dev.payswarm.com/i/manu If you go to the WebID above, you can see that the public key associated with the identity IRI is at the bottom right of the page. The data is also machine-readable via RDFa. This means that any software agent can be told who to trust and who not to trust by listing a bunch of IRIs. You also know if you can trust the IRI if another IRI can vouch for it. For example, if you trust VeriSign and they have said that they trust the IRI above (via a digital signature), then you know that you can probably trust the IRI above. You can also assert that you don't trust the IRI above for whatever reason. So, the power on who to trust and who not to trust should ultimately be in the hands of each and every person. This is true today with SSL certificates, but we want to make it a bit easier to make these sorts of statements online with WebID and PaySwarm. Note that WebID isn't a requirement for PaySwarm, we just think there are some useful aspects of it that we can use. Namely, 1) The ability to specify an identity via an IRI. People shouldn't be exposed to this level of detail, and should probably have a nice UI that they can use to browse identities, instead. 2) The ability to specify a public key and associate it with the identity IRI. 3) Ensuring that #1 and #2 are machine readable via RDFa or some similar automated data extraction mechanism. With those three simple concepts above, we can build a robust trust framework that is agile and decentralized for Web Payments. This is currently what the PaySwarm implementation does for machine-readable identity, including the expression of public keys (used to verify digital signatures). -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: Uber Comparison of RDFa, Microformats and Microdata http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/
Received on Saturday, 27 August 2011 20:50:16 UTC