Re: Question/idea: Self-contained WebID

Thanks for the information.

On 05/28/2014 12:14 PM, Kingsley Idehen wrote:
> 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.
I have no problem with HTTPS/TLS and would love to use it as often as I
can.  My main problem is that the real "openness" of HTTPS is dependent
on the certificate authorities.  StartSSL is free, so a person setting
up a small website with a forum can obtain a free certificate for their
site, but should they start charging, then it becomes restricted by the
price it may cost to obtain a certificate. Sometimes I wish there was a
viable alternative to the CA system.
>> 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.
I'm only slightly familiar with server-side programming in PHP as an
interest/hobby.  I guess once the user visits a page that needs the
client certificate, a PHP script an set some type of header back to the
client cause it to prompt for a certificate on the client, and once
submitted, the script would get access to that information via some
variables: _SERVER['HTTPS_CLIENT_CERT'] or something like that?
>
>>
>> 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.
>
If I have several sites I visit and they all use the WebID
http://www.mysite.com/myid#bav, then later my domain expires or changes,
what happens?  Do sites that use WebID provide a way to re-associate my
account with those sites to another WebID in case such an event happens,
and if so, how would I gain access to the accounts on those sites in the
event that the WebID Profile is not accessible (still trying to get my
head around some of this).
>>
>> 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).
>