On Thu, 23 Mar 2006, Peter Davis wrote:
I think this thread has (at least for me) is teasing out a new
requirement. It underscores the need to ensure support for non-HTML
aware HTTP clients. While many of the DAV clients Lisa enumerated use
shared HTTP engines, they may not always avail themselves of shared HTML
engines.
As a result, perhaps a new requirement may look like:
- the protocol shall support the transfer/transport of security tokens
over HTTP, but does not require implementations to support the HTML form
controls <form> and the associated encodings (eg: Calendar Clients,
FS-browsers, etc...)
There are dozens of deployed web signon schemes using a third-party
authentication service (eg SXIP, the SAML browser profiles, OpenID, etc),
and to my knowledge all of them make use of all the browser features
(redirection, cookies, form-based username/password entry) that make them
not applicable to non-browser HTTP user agents. Organizations base their
authentication strategies around these schemes, all of them aware that
these schemes are web-browser-only. They do this because, guess what, the
apps of interest are also web-browser-only apps, and those apps are
web-browser-only because they also want to work well with browsers so they
use all those browser-only features. We all use these apps constantly.
So it certainly would be a good thing to have an authentication system for
all HTTP purposes with all the wonderful properties we're seeking
(internet scale, ease of deployment, identity-info exchange, etc). This
is true in the same sense that it would great to have such a system for
IMAP, SMTP, LDAP, CIFS, NFS, etc etc. For my organization and my
community, I think good HTTP authentication is about as important as good
authentication in all those other app protocols. And none of them is
nearly as important as web authentication (ie, authentication of browsers
to web-browser-oriented apps).
(See
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
for discussion of improving HTTP authentication, btw.)
My point is that, odd as it may seem, web authentication, as deployed in
zillions of instances today, has almost nothing to do with HTTP
authentication. Insisting that a single scheme support them both, or a
single Working Group effort make both work equally well, is adding a
pretty serious amount of additional work and constraint on the solution.
Maybe the emerging importance of RSS and AJAX and WebDAV and Caldav and
their use in web-app scenarios changes the balance and makes us want to
tie web authentication and HTTP authentication together more than we used
to. Could be. But I think there is much good work to be done on
developing and deploying really good web-app-only schemes while we also
work on that grand convergence.
- RL "Bob"
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
