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.
Cheers,
reto
If authorization fails, a 401 should be returned.
On Fri, Aug 13, 2010 at 10:49 AM, Bruno Harbulot <
Bruno.Harbulot at manchester.ac.uk> wrote:
> Hi,
>> On 12/08/2010 21:05, Akbar Hossain wrote:
> > Hi,
> >
> > Wondering if it makes sense to specify/standardise the possible HTTP
> > status codes the resource you are trying to access should try to
> > respond with.
> >
> > http://en.wikipedia.org/wiki/List_of_HTTP_status_codes> >
> > Curious how/if TLS errors/failures should be communicated back to the
> > identifying agent.
>> The problem with TLS errors is that they close the connection, so you
> don't even get to reach the HTTP layer to provide any HTTP status code.
>> Some of our implementations let any certificate through and then let the
> application at the HTTP layer decide.
>> In principle, failing to authenticate should return a 401 status code.
> Unfortunately, this requires a WWW-Authenticate challenge associated
> with the response (there's a MUST in the HTTP spec for this).
> There aren't any WWW-Authenticate scheme for telling the user agent that
> its transport layer (TLS) should send another certificate or this sort
> of things.
> I've tried to suggest it a while back, but I got mixed answers at the
> time. I'm not sure what the interest from browser vendors would be.
>>http://www.ietf.org/mail-archive/web/tls/current/msg05589.html>>> In practice, though, it seems that browsers don't mind not having a
> WWW-Authenticate challenge when they receive a 401 status code. The
> problem is that they don't necessarily know what to do with it.
> I think it would be neat to be able to convey a bit more information in
> that challenge, for example enough to tell the browser to use another
> certificate issuer or to say that it's expecting a WebID certificate.
>>> Best wishes,
>> Bruno.
> _______________________________________________
> foaf-protocols mailing list
>foaf-protocols at lists.foaf-project.org>http://lists.foaf-project.org/mailman/listinfo/foaf-protocols>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100813/dbed55c5/attachment.htm