- From: Keith Moore <moore@cs.utk.edu>
- Date: Sun, 17 Jun 2007 11:16:17 -0400
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: Chris Newman <Chris.Newman@Sun.COM>, Apps Discuss <discuss@apps.ietf.org>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Eliot Lear <lear@cisco.com>
>> I would speculate it's because the following mandatory pieces of a complete >> DIGEST-based solution were never written down: >> >> * Client UI requirements >> > > Sure, but how much of this is the role of IETF? > > Since when do IETF specify client implementation besides what impacts > the wire protocols? > Traditionally we try to not constrain client design more than necessary, but that doesn't mean we strictly limit ourselves to defining what happens on the wire. And to the extent that we have limited ourselves, if we're learning that this is not sufficient, that's a good reason for relaxing that limitation. > Also don't forget that HTTP has widespread use in many applications > where there is no UI at all. > IMHO it would be reasonable to define a profile of HTTP for use with interactive web browsers. >> * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support >> > > As first point above, but server implementation. > I don't see why we shouldn't describe these things if doing so helps acceptance and interoperability. Perhaps as informational rather than normative text, but we should make sure that there's a complete picture. These things are important to the success of an authentication system. A lot of our failings in the area of authentication have been due to failure to consider more than just the on-the-wire protocol - we haven't tried very hard to make our technology accessible to potential users. Keith
Received on Sunday, 17 June 2007 15:17:06 UTC