- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 12 Apr 2011 11:31:32 -0400
- 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