- 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