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
