- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 28 May 2014 12:14:56 -0400
- To: public-webid@w3.org
- Message-ID: <53860B80.2050200@openlinksw.com>
On 5/28/14 9:56 AM, Brian Allen Vanderburg II wrote: > I'm using the overview section at http://bblfish.net/tmp/2011/04/26/ > > This is what it seems to be saying. Please correct any misconceptions. > > The server that you log into must support HTTPS/TLS. This means either > spending money on an SSL certificate for the website or using StartSSL > for free at least as long as it is provided for free (or self-signing > and the user getting warnings about the certificate all the time). It also applies to the likes of Dropbox, Google Drive, Micrsofot OneDrive, Box., and others i.e., HTTPS support isn't a problem. Secondly, the "TLS" in WebID=TLS implies a TLS dependency. WebID-TLS uses the TLS handshake as part of the identity claims verification process i.e., successful verification of messages signed using the local private key that's paired with the X.509 certs Public Key. > Since the X.509 cert. is sent to the server, how does the web > application that is being logged into get access to the information > needed from the cert? When the handshake is completed successfully, the following occurs: 1. de-referencing WebID from the certs. SAN which resolves to a WebID-Profile document (content takes the form RDF statements) 2. location and comprehension of the RDF based relation that associates the WebID with the Public Key of the Cert. used in the successful TLS handshake from the step above. > Does this require the web server to handle the > authentication via some CA specified in the web server configuration, No, that's an optional modality outside the base spec. > or > can the web application handle the checking of the cert via PHP/ASP/etc? Yes. > > The server hosting the WebID profile doesn't have to be SSL. It is just > whatever URL is specified in the client-side X.509 certificate. The server has to support TLS. Basically, HTTPS needs to be involved. For instance, you can pull this off by redirection. My WebIDs aren't always https: scheme based HTTP URIs, but that kind of redirection does require more control and sophistication on the part of the server providing WebID-Profile document storage. Thanks to Heartbleed, https: is now broadly supported by storage and service providers in general, they have no excuses to continue resistance. > > The client-side certificate references the WebID URL. If the location of > the WebID Profile changes for whatever reason (server shutting down, > domain name change), is it enough to edit the local client-side > certificate and change the URL field to point to another location for > any sites using it to keep working at the next login? > This would > probably break any web of trust that depends on the URL specified, but > could allow for keeping login working by moving the WebID Profile > somewhere else and updating the client-side certificate once? You make a new certificate. Even better, when setting up your local identity claims, simply pack them into an pkcs#12 bundle [1] (that's what YouID [2] does). You can then put the pkcs#12 bundle wherever you want, and use that to move the same local/private identity credentials across devices. Remember, every modern OS has in-built support for pkcs#12 files, so a file open event will invoke native interaction with the local keystore or keychain manager. > > Is it possible to generate your own WebID offline for use with multiple > sites by importing it into the browser and hosting the WebID Profile > online somewhere, or does it require an online site to generate? YouID does all its works offline. It then publishes the result of its work (where private information is packaged using a pkcs#12 bundle) to locations of your choice. > > Overall it looks very interesting and I definitely think that some > standard like this should exist and become widespread. Yes, its just a matter of navigating around the noise and confusion that swirls around: 1. RDF 2. Identity 3. Crypto 4. Semantics 5. Structured Data Representation 6. Authentication Protocols. Identity Management is crucial to everything. That's why open standards such as WebID, WebID-TLS, RDF etc.. attract such consternation. They are fundamentally democratizing one of the Web's final impact areas. Your Identity belongs to You. It should never belong to a 3rd party that ultimately seeks to lease it back to You! Links: [1] http://en.wikipedia.org/wiki/PKCS_12 -- PKCS#12 [2] http://youid.openlinksw.com -- YouID home page [3] http://bit.ly/1nBEeyA -- showing the effects of Google Drive as the storage provider for one of my WebID-Profile documents (in this instance my Amazon Persona). -- 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 28 May 2014 16:15:22 UTC