[foaf-protocols] Webid Spec: HTTP status codes?

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Fri Aug 13 16:21:16 CEST 2010



On 13/08/10 13:57, Reto Bachmann-Gmür wrote:
> Hi
>
> To me it seems the authentication layer should be at the tls layer, if
> the webid cannot be verified the cert should not be accepted and the
> client should (I know most don't) give the possibility to choose another
> cert or connecting without supplying a cert. I recognize that due to
> browser usability limitations some implementations may prefer to accept
> any cert provided and deny access with explanation on the http layers,
> however this doesn't give the client the possibility to change something
> on the tls layer.

Sure, but the problem is that the TLS layer gives little scope for 
feedback regarding why the certificate wasn't accepted. There are only a 
handful of error codes and they just break the connection, without 
giving much context.

What I was suggesting is to complement that (perhaps using some 
re-negotiation) with suitable information at the HTTP layer (so a 
non-trusted certificate wouldn't be accepted, but simply ignored rather 
than terminating the TLS connection).
This is of course not a trivial thing to do, since it would require some 
work on both sides (client and server).


> If authorization fails, a 401 should be returned.

Well, HTTP has always treated 'authentication' and 'authorization' quite 
ambiguously. In most cases, 'unauthorized' actually means 
'unauthenticated and therefore unauthorized'.

The problem with 401 is in the 'MUST' 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2>:
    "The response MUST include a WWW-Authenticate header field (section 
14.47) containing a challenge applicable to the requested resource."


Best wishes,

Bruno.


More information about the foaf-protocols mailing list