- From: Scott Lawrence <lawrence@agranat.com>
- Date: Tue, 25 Nov 1997 13:51:13 -0500
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>>>>> "RP" == Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com> writes: RP> "Scott Lawrence" <lawrence@agranat.com> writes: >> As I wrote the proposal, 'discard' can't be combined with other uses >> of the Authentication-Info header, such as nextnonce; this may have >> been a mistake. RP> Just to be clear: You're proposing that a client receiving an RP> "Authentication-Info: Discard" header in a response should discard the RP> credentials it supplied on the Authorization header in the request, RP> correct? Given everything Fote has been saying about the domain of RP> credentials over URLs, not to mention realm values, it's entirely RP> possible for a browser to have a large cache of presumably-valid RP> credentials. I don't think you're asking to have them all discarded, or RP> even some subset of those associated with the origin server, correct? Yes, correct. My intent was that the credentials used for the request be discarded - regardless of what other protection spaces they may have also applied to. Credentials not used for the request are not affected. Example: get /foo ------------------> <----------------- 401 Unauthorized WWW-Authenticate: realm="bar" (prompt user) get /foo ------------------> Authorization: xxxxx <----------------- 200 Ok ... get /foo/bogus ------------------> Authorization: xxxxx <----------------- 200 Ok ... post /foo/bar ------------------> Authorization: xxxxx <----------------- 200 Ok Authentication-Info: discard (discard credentials use to build xxxxx) At this point, if the user enters the URL for /foo/bogus, the user agent may 'remember' that it needs to prompt for credentials in realm 'bar' or it may just send a request and (presumably) get a 401 as usual. The fact that 'discard' came in response to a request for /foo/bar does not restrict the loss of credentials to that resource - the credentials go away and must not be reused. If people don't think that was clear, I invite improved wording. RP> One more point: Since Authentication-Info is defined by RFC 2069 as RP> being sent when authentication is successful, this discard response must RP> be sent with a 2xx or 3xx status code and without a WWW-Authenticate RP> header. In other words, an origin server is only allowed to request the RP> client to discard credentials at a time when they are acceptable to the RP> server. I had not made that specific, but I see no problem with it. RP> And I assume we'd want to support "Proxy-Authentication-Info: Discard" RP> as well. I will leave that to those who believe that they understand proxy authentication... RP> I have to say that this is all starting to sound like something we RP> aren't allowed to do while trying to move HTTP/1.1 from Proposed to RP> Draft Standard. As much as the lack of a procedure for invalidating a RP> client's credentials has hurt my company's products (quite a bit!)... It is clear that this capability, if it existed, would be a big help to application developers. I believe that a good case can be made that its absense decreases the security of many applications, and so I would argue that it is a bug in the protocol - bugs may be fixed at this stage. I also believe (as I said in the earlier note) that it does not present a backward compatibility problem (web applications using old browsers will be bug-for-bug compatible with the old protocol :-). RP> ... we RP> would nonetheless be opposed to any change that would prevent the rapid RP> advancement of HTTP/1.1 to Draft Standard. I could not agree more. -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Tuesday, 25 November 1997 11:07:17 UTC