- From: <Eric_Houston/CAM/Lotus@lotus.com>
- Date: Tue, 9 Dec 1997 18:00:00 -0500
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> Digest authentication already includes a mechanism (the 'domain' >> attribute; see section 3.2.1 of draft-ietf-http-authentication-00) to >> specify that credentials may be used on multiple servers, My vision is to move away from requiring directories to be replicated on content servers. While the re-direction for authentication may seem awkward, it is essentially equivalent to doing the directory transport in real time via LDAP on the back end. I don't know much about digest authentication just yet (but I'm getting the feeling that I am going to be learning about it real soon) but I'm not convinced that it is solving the right problems... >> There is also the model of Kerberos to consider - developing a >> ticket-based authentication scheme (with the advantages and problems of >> any third-party mechanism) would be another area to explore. When you say Kerberos, do you mean OMTX signed URLs? They are excellent for associating arbitrary authorization semantics with a URL. They include the semantics and a MAC for security. That is what I had in mind when I said that the browser should cache another string of arbitrary length: the implementation can use it for ticketing. -e Scott Lawrence <lawrence@agranat.com> on 12/05/97 01:53:46 PM To: Eric Houston/CAM/Lotus cc: http-wg@cuckoo.hpl.hp.com Subject: Re: Proposal for new HTTP 1.1 authentication scheme Digest authentication already includes a mechanism (the 'domain' attribute; see section 3.2.1 of draft-ietf-http-authentication-00) to specify that credentials may be used on multiple servers, and through the 'digest' attribute allows for mutual authentication. There is also the model of Kerberos to consider - developing a ticket-based authentication scheme (with the advantages and problems of any third-party mechanism) would be another area to explore.
Received on Wednesday, 10 December 1997 01:36:01 UTC