Re: domain attribute in digest auth

> I don't know of any scenario where I'd want to point my browser at multiple
> proxies that aren't in the same protection domain.

How about if authenticated proxies are used to allow and limit access to
intranets from the outside? Or if a corporation wants to split their
intranet into divisions or BUs and provide access to outsiders via
authenticated proxies? I have no idea if anybody is doing this or wants
to do this, but then again I keep keep getting surprised at what kinds
of applications and setups are being built. If all proxies are put in
the same protection space then you're cutting off these sorts of
possibilities. By making proxy auth work similar to server auth you are
leaving the possibility open.

> I don't know how to even configure any browser to do that.

Netscape at least allows for script based setting of proxies and if my
memory serves me right you can set different proxies for different URLs.
Don't know if it handles multiple proxy-auth correctly, though.

> Even so, if need be, realm name space can
> be allocated from the DNS name space and hence be globally unique.

True, but then you have to tell people to do so. Also, since the realm
value is just about the only way a server can get some info of sorts in
the auth dialog box on browsers, it's used by a number of sites to to
provde additional info (I'm not saying this a great idea...). These
folks I believe would rather not have to litter the "message" with an
extra DNS name just to guarantee uniqueness.

The question though is why go through all this? What are you trying to
gain by ignoring the domain attribute? It doesn't simplfy the client any
(since you can use basically the same code for both server and proxy
auth), nor do I see it simplyfying the proxy much, nor does it simplify
the spec (you'd need to add words about the necessity of making the
realm globally unique).


  Cheers,

  Ronald

Received on Sunday, 4 October 1998 00:15:27 UTC