W3C home > Mailing lists > Public > public-webid@w3.org > April 2015

Re: Regarding WebID Certificate in TLS

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Fri, 24 Apr 2015 12:03:25 +0200
Message-ID: <CAKaEYh+PfN61kF6jdsjv504qdbmzs0_+efF9253za=6qAaH=Ew@mail.gmail.com>
To: "fumugami@gmail.com" <fumugami@gmail.com>
Cc: public-webid <public-webid@w3.org>
On 24 April 2015 at 07:09, fumugami@gmail.com <fumugami@gmail.com> wrote:

> Hello,
> I’m just an individual interested in the idea of a decentralized identity
> like WebID.


> I want to enquire you about the reason that led you to use an X.509
> certificate in TLS authentication..
> X.509 certificates are part of the Directory system. It is a system used
> widely in centralized, hierarchical environments, where entities are named
> by their hierarchical Distinguished Names. The X.509 certificate is a
> signed verification that a certain public key belong to the given entity
> identified by a Distinguished Name. This claim is verified by an entity
> with higher priviledges, which is trusted.
> Now, when you send an X.509 certificate, the client or server has a list
> of trusted CAs and it verifies that the chain of signatures on the received
> certificate is valid. This is done LOCALLY, without contacting anyone. The
> only place a remote resource is fetched is to get a CRL that can invalidate
> a given certificate, but that list is also signed by the CA and then
> verified locally by the client/server.
> In WebID you are proposing a decentralized system, where the entity is
> authenticated by sending a CLAIM of their identity, which the server then
> veririfies by contacting a REMOTE resource. This is completely different
> from what X.509 certificates are designed for. It would be better and wiser
> to do it like this:
> 1. In order to support WebID, the server sends a CertificateRequest with a
> webid(TBD) ClientCertificateType value. The "certificate_authorities" list
> is empty or ingored.
> 2. The client sends something like this as the Certificate message:
> struct {
>   uint8 version; /* In case the definition changes later */
>   opaque webid<1...65535>; /* The WebID identity URI */
> } WebIDClaim;
> 3. The server, upon receiving the above, fetches the associated public key
> from the Profile Document using the URI in WebIDClaim.webid.
> 4. The client sends a ClientKeyExchange with the pre-master secret
> encrypted with its WebID private key.
> 5. The server decrypts the pre-master secret with the fetched public key.
> This key is claimed to be the client's. If the public key is incorrect,
> this will result in an incorrect master secret and the handshake will fail.
> 6. If the handshake succeeds, the WebID is verified and the client
> authenticated.

This may be of interest to you:


Is it along the same lines?

> This would make the handshake message smaller, and allow implementations
> to separate WebID code from X.509 code. The server's WebID verification
> process is a process of verifying an unknown claim. It relies completely on
> the trueness of the Profile Document and that it is fetched correctly and
> from the right source. There is no certificate. Nothing is certified prior
> to receiving the identity claim.
> Anyway, I think the major obstacle in adoption of a decentralized solution
> is that most people are used to be governed by some kind of single
> government and the idea of a decentralized system brings anarchy and chaos
> to mind.

Yes, in the last 5+ years this has been the case.  I've been building apps
for webid+tls, but it's really hard to find even a dozen active users.  By
far the most used deployment of WebID is with facebook authentication.

> Do I need to subscribe to receive responses? I don’t know how exactly
> mailing lists work.
Received on Friday, 24 April 2015 10:03:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 24 April 2015 10:03:58 UTC