Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis

[[e-mail]]

Henrik,

> There is imho three primary reasons why Digest has not gained much
> foothold, neither being security.
>
> a) Implementation rather complex, with few if any implementation getting
> it entirely right..
>
> b) It's inability to integrate well with existing authentication
> frameworks on the server side.
>
> c) UA integration, or web site owners requiring control over the login
> process beyond a standard "login+password" dialog.
I think that you got that perfectly right.
My opinion is, that a) could be improved by a strictly editorial revision
of RFC2617 while c) requires substantial revision of the contents.
I do not consider b) to be a problem of the spec but of the implementors.
For me it seems that the real obstacle for RFC2617's popularity is c). 

People just seem to insist on having their authentication procedure in the 
"look-and-feel" they want it to be and concrete-cast it into their
HTML/flash/whatever-content (even though that may seem to be a silly idea
from a usability point of view).

Maybe a solution just like rfc2388 could be suitable here.
Needed is a well-defined way to interact between the application
and the protocol -- the only difference here is, that the auth stuff
needs to interact with the HTTP header, while the form submission stuff
needed/needs to interact with the HTTP POST body.
I guess that a similar "bridge" could be a solution for the problem.

Of course that would need interaction with HTML, e.g. it would need
the introduction of 
<input type="authuser" /> together with <input type="authpass" />
or the like, which are defined to have their contents be passed on
to a well-defined HTTP-Auth scheme.

It could even be done without the need to (substantially) change the
HTML spec, e.g. by reserving special form element ids for that purpose,
lets say
<input type="text" id="authuser" />
<input type="password" id="authpass" />
or the like.

Having that said I would tend to use a double tracked approach:
- editorial revision of rfc2617 to make existing impls
  or new impls that have to interact with them happy
- simultaneously develop a "completely new" scheme that does
  not have the fundamental deficiency of being unable to interact
  with the "application layer"

Kind regards

Ingo Struck