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 15:53:06 +0200
Cc: WebID XG <public-xg-webid@w3.org>
Message-Id: <03F7289D-FEE4-4027-81C1-1F95557EBB45@bblfish.net>
To: Andrei Sambra <andrei@fcns.eu>

On 12 Apr 2011, at 15:36, 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. 
> 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.

That is server specific. But ideally you don't want that at all. If the user
does not provide a certificate, the server should just have the user logged in
as anonymous, and allow him to authenticate using username/passowrd, openid, ...

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

yes. If the keys don't match then the server throws one of the TLS exceptions,
which should generate a readable message from the client. There are TLS exceptions
for certificates out of date, and for invalid certificates....

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

Yes, or just don't log the user in. In clerezza I keep the certificate so as to
be able to explain the issue with the certificate. 

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

yes, for all the above. But replace most Goto 0, with authentication fails.
The user is thus not authenticated. Error messages can be shown.


> ---------------
> Andrei

Social Web Architect
Received on Tuesday, 12 April 2011 13:53:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC