Re: Question/idea: Self-contained WebID

On 5/28/14 1:52 PM, Mo McRoberts wrote:
> I don’t know if it’s been covered, but if you sacrifice attribute exchange (or rely solely on attributes baked into the cert itself), you could do TLS-based “WebID” with a URI which is verifiable only using the public key in the cert.

Yep!

> For example, it’d be ugly (though who cares if your WebID URI is ugly if you never have to see/type it?), but you could do it with a URN containing your key algorithm and pubkey hash (e.g., urn:rsakey:<fingerprint>) — as an informal URN scheme it’d only take a couple of weeks to bring into life if somebody was really keen.

We use a number schemes in this regard, so the SAN can even be empty and 
Turtle is added to the cert via data: scheme.

On the server side we accept:

1. cer: -- we made that one up
2. di: -- emerging scheme for digest data
>
> Server-side applications could even use that as a default URI for an agent as a matter of course, adding a resolveable URI as a preferred alias if one’s available.

Yep!

Basically, we see what you describe as a lightweight (but effective) 
option for verifying the subject of an X.509 cert. via a test on 
"mirrored claims". For instance, coincidentally, we are about to release 
licenses for HTTP, ODBC, JDBC, ADO.NET, OLE-DB clients into the LOD 
cloud via some of our live instances. This is all driven by X.509 certs 
comprised of claims verified using the approach you describe. The only 
difference is URI scheme :-)

I've attached a sample certificate.

We are keen, and its critical to the machine-machine stuff we are working.
>
> M.
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen