[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