Re: Question/idea: Self-contained WebID

On 5/28/14 1:36 PM, Brian Allen Vanderburg II wrote:
> 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.

Some of us would contend that the real problem lies in the browser and 
the misconceptions it presents to end-users in regards to TLS. For 
instance, CAs are useful in situation where 3rd party notaries are in 
fact beneficial e.g., eCommerce. We don't need them when sharing HTTP 
accessible resources within Trust networks, for instance.

If I am paying money to a vendor that claims to be Amazon, I certainly 
need some 3rd party (acting as a notary) to verify the Amazon identity 
claims.

If I am sharing a photo with you, I can even issue you the certificate 
that contains all the information that I've used to craft an ACL or data 
access policy etc. All you do is present the Cert. when challenged.

>   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?

Yes, sorta. There are PHP code sources in regards to WebID-TLS 
implementation [1] .
>>> 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?

You update the RDF statements in your WebID-Profile document, accordingly:

<http://www.mysite.com/myid#bav> rdfs:seeAlso <#newWebID> .

or

## But this is a little complicated to pull-off safely.

## Statements need to be reified and then signed in the WebID-Profile 
document.
## Otherwise:
## The transitive nature of owl:sameAs relations also needs to be 
conditional, which takes us from owl:sameAs to :sameAs (i.e., sorta 
sameAs in a different ontology)
## Inference and Reasoning too has to become conditional etc..

<http://www.mysite.com/myid#bav> owl:sameAs <#newWebID> .



>   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).

As per comment above, but WebID isn't that wide spread right now, so we 
can actually start to think about these usecases (again).

Mo's suggestion in an earlier post, which I acknowledged is something we 
already implement, ultimately provides an alternative to the RDF 
statements above i.e., the URI that denotes certificate's subject 
doesn't even need to be an HTTP URI per se., then you can work with the 
claims in the Cert (even use the data: extension to add RDF statements 
into the Cert) as fodder for a server that implements a protected 
resource ACL .

The problem with this approach above  is that it veers away from the 
HTTP URI denotation function of a WebID. As a consequence, It loses the 
flexibility provided by the Web's resource (file) create, save, and 
share pattern i.e., you end up squeezing data using ASN.1 into a Cert 
where you could just use Turtle to express relations that are only 
limited by our imagination.

>

Links:

[1] https://github.com/WebIDauth -- PHP implementation example .


-- 

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