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

WebID prehistory

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 3 Feb 2011 12:19:59 +0100
Message-Id: <4449FBEA-408D-472A-875F-3210A6B0A4B4@bblfish.net>
To: WebID XG <public-xg-webid@w3.org>
Peter Williams has mentioned how close WebID is to what X500 wanted to be. Here is a recent intervention of his:

On 3 Feb 2011, at 05:26, Peter Williams wrote:

>  In the original X.500 strong auth model, one could have a directory entry/container of name N any number of user certs, of any subject name. There was no relationship between the container name and the subject name in the cert (in the formality of the standard that is, though in practice there often was). Presence in the entry proved someone had expoited write-privs within the security policy, to publish it there. Having cited a cert bearing a subject name claim, the relying party only had to do one thing: confirm that the very same cert bytes, in canonical encoding, were present in the container located by the claimed subject name. The verifier thus ahd to "trust a name resolver", to correctly lcoate a container, given a claimed name. The resolver also had to trust the server, to be correctly enforcing its access control model. 
> If the container had the name dc=auchentoshan, dc=cs, dc=ucl, dc=ac, dc=uk and a yellow pages entry had a name host=auchentoshan,o=UCL-CS, l=Internet, if the subject field in a cert presented to a server was the latter and the same cert was to be found in the entryd once the name resolver had done its location thing to retieve the entry and its various attributes, then the cert was "valid".

I think we should develop this a little by comparing it with what WebID does and how the semantic web helps solve the problem of the meaning of ldap directories, how it helps link across ldap directories, and so why WebID helps turn the X500 vision into a global one, not just one tied to a company... 

In another post I think I understood Peter to have written wrote that early SSL implementations would fetch the certificate from the X.500 directory. The client would not send it as it does now to the server. So putting the certificate in the client could be thought as a sort of caching mechanism.

It would help to have a clear write up of this, factually verified, with proper citations, because this would then help show how we are fulfilling the X500 dream, and help align the X500 people's intuitions with the semweb world.

Should I add this as an issue.


Social Web Architect
Received on Thursday, 3 February 2011 11:20:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:41 UTC