On 14/06/2011, at 10:40 AM, Dave Kok wrote:
>> What do you mean by "it's a protocol thing"? The idea is to provide a UI to
>> enable a human to interact with the protocol, this must be present in some
>> way, either by the UA as at present, or through forms as suggested.
> Personally I prefer the perspective that you are providing a UI for the use 
> case 'to log in', not to give access to the protocol.

Yes, this is how we would like to implement this on a service or application 
level however it is not what http authentication requires for the protocol.

Http authentication is stateless (state held by UA, not protocol) and it must 
be, potentially, applied to any request. Therefore it must be possible to 
additionally declare authentication on any form, constructing any 
representation, using any protocol method.

That the UA retains authentication and automatically applies to subsequent 
requests only allows for the possibility for a single-use login form to be 
authored. The login form would be used to tailor a request's headers and not 
specifically for the construction of a URI or form-encoded representation, 
although this would additionally be possible.

> If you limit it to a use 
> case without knowledge of the protocol you also allow for broader 
> implementation. For instance when the HTTP protocol isn't used.

There is nothing explicitly tying the design to the http protocol, especially 
if input type of 'header' is viewed as capturing metadata for a protocol 
request.

> Using forms as 
> suggested I fully support. But my preference is to limit the forms to 
> gathering the information needed to login and let a user-agent worry about 
> the 
> details.

Yes, it is the ideal to have this level of abstraction but it is also an 
abstraction based on a single use and so looses any potential general 
applicability through lack of specification. All logins can't be reduced down 
to just a username\password and a domain, but some authentication models can.

> I would expect that the only information required is the user's 
> credentials and perhaps a domain (never fully read up on digest 
> authentication). If you disagree then I am afraid we have to settle on this 
> by 
> agreeing that we disagree.

Very well, i will stand in disagreement :)


[snip]
> Binding on a new attribute gives authors a choice.

The introduction of a new input element type 'header' is the new attribute 
which may activate new behaviour. 

> They can 
> either choose to include both a name attribute and the new attribute for 
> binding and things are as you commented. Or authors can use a different 
> approach. What worries me is that if a author does not account for 
> user-agents 
> not handling the authorization, the user's credentials are sent in the clear 
> for all the see, especially when using the GET method. 

For plain text passwords to be visible in the URI in an old non-compatible 
browser, the author will have chosen to use plain http (no ssl) and as a GET 
request. If the form is set to POST it will operate the same way people send 
passwords through forms today.

Thanks,
Cameron Jones

Reply via email to