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

Re: Authentication workflow draft.

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 12 Apr 2011 11:31:32 -0400
Message-ID: <4DA47054.7070604@openlinksw.com>
To: Henry Story <henry.story@bblfish.net>
CC: Andrei Sambra <andrei@fcns.eu>, WebID XG <public-xg-webid@w3.org>
On 4/12/11 11:00 AM, Henry Story wrote:
> 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.

Yes, that would be fine.

Kingsley
>> 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/
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Tuesday, 12 April 2011 15:32:00 UTC

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