W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: Authentication workflow draft.

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 12 Apr 2011 17:00:01 +0200
Cc: Andrei Sambra <andrei@fcns.eu>, WebID XG <public-xg-webid@w3.org>
Message-Id: <277E2B9A-ED12-48E7-AD05-DA3C3CBEB9C4@bblfish.net>
To: Kingsley Idehen <kidehen@openlinksw.com>

On 12 Apr 2011, at 16:48, Kingsley Idehen wrote:

> On 4/12/11 9:36 AM, Andrei Sambra wrote:
>> After a chat with Henry today, we decided to draft a "workflow" to
>> describe how the authentication process takes place from the moment a
>> user is accessing the service.
>> 
>> We are assuming the user possesses a client certificate which is
>> installed in his browser, as well as a publicly accessible WebID on the
>> web. The URI of the webid is found in the certificate's subjectAltName.
> 
> What happens when the SAN URI (WebID) isn't "http:" scheme based? That's a critical test.

If the server does not know how to deal with it, the user is anonymous.
In the tests we should have an way for the server to tell that he does not know how 
to deal with a URI type.

> 
> Kingsley
>> Note: GOTO is used for the sake of simplicity and should not be
>> generally used! :-)
>> 
>> Feel free to comment/add/change stuff if you consider it important.
>> 
>> -----------
>> 
>> Step 0. Init / no authentication / authentication failed (implementation
>> independent)
>> 
>> Step 1. The user connects to the authentication server (service) and is
>> asked to provide a certificate.
>> 
>> Step 2. The user selects the certificate and clicks the submit button.
>> If the user does not provide a certificate, GOTO Step 0.
>> 
>> Step 3. Using TLS, the server verifies that the public key found in the
>> certificate matches the user's private key. If the keys do not match,
>> (print an error maybe) GOTO Step 0.
>> 
>> Step 4. The server verifies the validity date of the certificate. If the
>> certificate has expired, GOTO Step 0.
>> 
>> Step 5. The server extracts any URI found in the certificate's
>> subjectAltName field, ignoring everything else (like email, etc.). If no
>> URIs are found, (print an error maybe) GOTO Step 0.
>> 
>> Step 6. For each URI found, the server fetches and parses the profile
>> file located at that particular URI, looking for resources pointing to a
>> public key (i.e. rsa#RSAPublicKey?). If no resources are found, (print
>> an error maybe) GOTO Step 0.
>> 
>> Step 7. If a public key resource is found, the server will try to check
>> if the contents of "cert:identity" match the WebID's owner. If no match
>> is found for any URI, then GOTO Step 0.
>> 
>> Step 8. If the identity matches the WebID, the server will try to match
>> the WebID's modulus and exponent values to the ones provided by the
>> user's certificate. It is possible to have multiple modulus values
>> (belonging to several keys) therefore the server should cycle through
>> all of them. If no match is found for any modulus/exponent of any URI,
>> GOTO Step 0.
>> 
>> Step 9. If the modulus values match, the client is authenticated.
>> 
>> ---------------
>> 
>> Andrei
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/
Received on Tuesday, 12 April 2011 15:00:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC