W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

RE: WebID, BrowserID and NSTIC

From: Peter Williams <home_pw@msn.com>
Date: Mon, 25 Jul 2011 20:43:58 -0700
Message-ID: <SNT143-w4987B33378B6A79EB5970892320@phx.gbl>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

In webid, there are 2 communities. There are those represented by the Henry camp that are CA-centric. Typically going by a name other than CA (though), a  third party agent mints a users certs *and arguably asserts its intellectual property controls such as copyrights and use controls). Typically, this agent is a golld old fashioned CA web site, using the HTML keygen tag enable a a pubkey to be signed using a CAs key and installed in a users browser (mozilla) or other key store (windows, Apple). Sometime the CA website calls itself "not a CA" - on the basis that it does no user identiication process; merely asserting its IP control system. In X.509 terms, this lack of user identiication is immaterial to the definition of a CA. A party that signs another pubkey inducing a third to rely is a CA. One can wiggle with semantic DEFINITIONS all one wants. But, this entity is a classical CA, even if you define it or name it otherwise. Nobody is fooled. What matters is WHOSE intellectual property is [partly] controlling inter-user activities  There are those represented by the Peter camp that have users issue their own self-signed certs (much like the PGP community). No third party is involved, and HTML keygen need not be used to make keys or make certs. This method is not in favor in the web vendor community, generlaly, as no server-side web vendors get to control users keys and thereby "deliver trust services" tied to server-side profile management. The spec doesnt mention the above distinctions.   If an email provider mints certs bearing webids, its in the Henry camp. Its just a CA. Its just a CA that happens to use email verification as the user identification criterion. There is nothing user centric about this world. Its just the TTP-centric CA world.From: henry.story@bblfish.net
Date: Tue, 26 Jul 2011 04:59:49 +0200
CC: nathan@webr3.org; public-xg-webid@w3.org; kplewison@pomcor.com
To: fcorella@pomcor.com
Subject: Re: WebID, BrowserID and NSTIC




On 25 Jul 2011, at 21:50, Francisco Corella wrote: We will soon revise the white paper to add WebIDs, and PKI certificatesissued by email service providers to assert that the user owns an email address.  We
also accomodate the submission of multiple credentials simultaneously,
which makes sense in several use cases.
very nice! Please keep us up to date on feedback from the NSTIC.
We should also look at using the PKI certificates issued by e-mail service providersas BrowserId does. I think it would fall under the topic of usingWebIds in Issuer Alternative Names. So an e-mail server is one possible issuer,but  one could also have WebServers be  issuers (CA) - as they are currently. After all if the public key used by the https server is the same as the one that signed the certificate, there is no need for the Relying Party to dereferencethe WebID, other than as a Certificate Revocation and RESTfulattribute exchange mechanism. (It may also be psychologically helpfulfor many people, because it could be that people have trouble understandingcertificates that are not signed by a CA.)
And yes, I agree there are many technologies that can come together.Being interested in the social web, my focus has been less on anonymity,than in decentralisation of sociality, which I think is the biggest issueat present.
I think that it is very difficult to achieve anonymity, as even if the tools are available users will very likely give away a global identifier if asked (credit card,e-mail, address), or something to the same effect: enough information tobe identifiable - and not much is required there.  But hey, if the technology tomake this possible is widely deployed, it will be great to be able to use it :-)
Henry

Social Web Architect
http://bblfish.net/


 		 	   		  
Received on Tuesday, 26 July 2011 03:44:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:25 UTC