RE: Documenting implicit assumptions?

folks may be interested in web history. 
 
Some of the first use of the object tag included activeX controls (signed). In the object properties, serialized properties could support verification of the properties. (W3C was highly involved in this signed code initiative - though few if any public records seem to exist of what it was really up to)
 
Later this evolved into data:...[hex], where the URI scheme generalized what the object tag had done when embedding or ferencing hex encoded proeprty values, each providing keying evidence to verify the signatures on the PE objects reference or communicated by the object tag.
 
Its like certain pre-web experiment I remember doing with the SMTP relaying world, in which my RFC822address was something like "pwilliams%hashhex@ames.nasa.gov (long hex string of public key)" - embedding "fingerprints" into resolvable names distributed in public mailing lists, much like some in W3C have a related idea of embedding PGP signatures into logic statements in public machine-redable documents (RDF). This is all a variation of a common theory, in which the source route is the secret information bearer; and where the public key is the publication of the name in the normal course of discourse.
 


----------------------------------------
> Date: Fri, 4 Feb 2011 16:17:32 +0100
> From: swlists-040405@champin.net
> To: tai@g5n.co.uk
> CC: public-xg-webid@w3.org
> Subject: Re: Documenting implicit assumptions?
>
> > (Anyone played around with "data:" WebIDs
> > yet? I've been thinking about them for some time, but my OpenSSL
> > wizardry is not quite up to it yet.)
>
> wicked :-D
>
> however, I don't think it works:
>
> there is no separation anymore between the certificate and the profile
> to which it points, as the profile is *embeded* in the certificate.
>
> So instead of proving that the owner of the certificate has/had write
> access to the given URI, you simply prove that they have access to the
> certificate itself, which is not much to prove ;-)
>
> pa
>

Received on Friday, 4 February 2011 16:43:21 UTC