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

[Akbar Hossain]

So in summary it sounds like some of the http and tls interation and
return codes stuff is aspirational. Which we should explore/ document
and action.

With regards to return status codes/scenarios that could/can be
specified. What are the next steps to get a draft. Happy to have a go
but there maybe more experienced/appropriate folks here to do it.
(Joe/Bruno maybe ;-) or is there sufficient for the editors pick this
up from here).

Looking for direction from the editors.

I think the process was discussed so apologises if i should know this already.

Or is there no agreement to add this to the spec at this time.

Thanks


On 8/14/10, Henry Story <henry.story at gmail.com> wrote:
> Perhaps these points should be added to the wiki, or put together on a page
> and then presented to the HTTP and TLS working groups at some point.
>
> Henry
>
>
> On 14 Aug 2010, at 22:30, Joe Presbrey wrote:
>
>> Increasing exposure of the SSL requirements sounds very useful if
>> browsers and mod_ssl will agree.
>>
>> Further, on an HTTP 401 (in a client-cert-optional setup) I think the
>> browser/server needs to break the SSL session and/or otherwise get the
>> user to reselect a certificate.
>>
>> The goal here would be to make the behavior of client authentication
>> with SSL consistent with that of Basic and Digest (re-popup username
>> and password).
>>
>> --
>> Joe Presbrey
>>
>> On Fri, Aug 13, 2010 at 5:21 PM, Bruno Harbulot
>> <Bruno.Harbulot at manchester.ac.uk> wrote:
>>>
>>>
>>> On 13/08/2010 20:33, Joe Presbrey wrote:
>>>> On Fri, Aug 13, 2010 at 10:21 AM, Bruno Harbulot
>>>> <Bruno.Harbulot at manchester.ac.uk>  wrote:
>>>>> 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).
>>>>
>>>> I agree. This should be described as a Best Practice.
>>>>
>>>>> This is of course not a trivial thing to do, since it would require
>>>>> some
>>>>> work on both sides (client and server).
>>>>
>>>> We can already do this with modifications to mainstream servers and
>>>> modules, Apache/mod_ssl, and have demos.  Or I didn't understand what
>>>> you were describing (sorry).
>>>
>>> I'm describing the fact that, instead of relying on the
>>> certificate_authorities list in the CertificateRequest TLS message as
>>> the sole way of giving a hint regarding which certificate to select (or
>>> error code for what went wrong), we could use a WWW-Authenticate header
>>> for this.
>>>
>>> For example:
>>>    WWW-Authenticate: Transport
>>> layer=TLS;trust_type=PKIX;certificate_authorities=x,y,z
>>>
>>> or (more appropriate for WebID):
>>>    WWW-Authenticate: Transport layer=TLS;trust_type=WebID
>>>
>>> even maybe:
>>>    WWW-Authenticate: Transport
>>> layer=TLS;trust_type=WebID;you_need_to_be_a_friend_of=http://www.example.com/user/#me
>>>
>>>
>>> I'm making this up of course and it would need a bit more thinking, but
>>> the idea would be to shift the task of negotiating which certificate to
>>> send from the TLS layer to the HTTP layer, thereby giving more
>>> flexibility (and the ability not to be "rude" to the client by closing
>>> the connection abruptly if there's something wrong with the certificate
>>> it send).
>>> This would also allow for multiple challenges on the same service (as
>>> it's already possible), e.g. Digest+Transport,
>>> Basic+Negotiate+Transport, although some of this is partly already
>>> possible since client-certificate authentication is already orthogonal
>>> to the others.
>>>
>>> This doesn't require so much work on the server side, perhaps just
>>> enough to be able to trigger the renegotiation (not actually that easy,
>>> depending on the type container and the API exposed).
>>>
>>> It's on the client side that this requires more work: the user-agent
>>> would need to support this, but I think the general certificate
>>> selection UI would improve if we had that in place.
>>> On the one hand, I think that's a long term goal. On the other hand, as
>>> far as I aware, servers could already send this sort of headers, since
>>> browsers don't seem to complain too much when they don't understand the
>>> challenge scheme in the WWW-Authenticate header (or when that header is
>>> simply missing).
>>>
>>>
>>>>> 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."
>>>>
>>>> Indeed on both counts. For responsible use of 401 in mod_authn_webid,
>>>> I must reinterpret this text, like I do other old commandments, from
>>>> within my own post-modern context:
>>>> "The response MUST include a [HTTP-standards-based] field containing a
>>>> challenge applicable to the requested resource."
>>>>
>>>> Of course for WebID, the "challenge" is the SSL client certificate
>>>> request.
>>>>
>>>> In general, 401 is for not authenticated and 403 is for not authorized
>>>> (or both).  AFAIK, this spec should be dealing primary with
>>>> authentication =>  401 unless we want to come up with some higher 40x's
>>>> to supersede my current 'specify the specific authentication error in
>>>> the response body' plan.
>>>
>>> The downside of 403, especially once your browser has chosen a
>>> certificate, is that you can't re-challenge and change the certificate
>>> easily (or know why it doesn't like the certificate). These problems are
>>> of course linked to the browsers' certificate selection UI.
>>> Typically, since I tend to have at least a CA-signed cert and a WebID
>>> cert in my browser and because we use an empty list of
>>> certificate_authorities to enable self-signed WebID certs, if the
>>> browser picks the CA-signed cert to send as a WebID cert (and since it
>>> doesn't have any URI in the subject alt. name), this could cause 403s
>>> (this doesn't really happen in the situation where the server expects a
>>> CA-signed cert, since the browser doesn't suggest the self-signed WebID
>>> cert in this case).
>>>
>>> I think you've got the right approach by using 401 and an explicit
>>> message in the response body, considering there's no standard
>>> WWW-Authenticate scheme to do this, but since browsers don't necessarily
>>> understand what's going on, they don't necessarily re-offer to send
>>> another certificate instead.
>>>
>>>
>>> Best wishes,
>>>
>>> Bruno.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>

-- 
Sent from my mobile device