W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

RE: Proposal for new HTTP 1.1 authentication scheme

From: Paul Leach <paulle@microsoft.com>
Date: Thu, 11 Dec 1997 19:11:54 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587203843@red-msg-51.dns.microsoft.com>
To: jg@pa.dec.com, "'Eric_Houston/CAM/Lotus@lotus.com'" <Eric_Houston/CAM/Lotus@lotus.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4944

> ----------
> From:
> Eric_Houston/CAM/Lotus@lotus.com[SMTP:Eric_Houston/CAM/Lotus@lotus.com]
> Two new refinements that I would like to make:
>  1) When the content server redirects the request to the authentication
> server, it encrypts the ACL for the protected resource.  The
> authentication
> server then validates the user against the (decrypted) ACL and returns the
> first matching entry to be cached in the browser.  When the browser is
> queried for user credentials, the encrypted (authenticated) group
> affiliations are returned to the content server.
You may do this if you want, but I'm not planning to spec the content server
(CS) to authentication server *AS) protocol as part of the proposal. I'll
give a sample one, perhaps in a separate draft, to make sure that one is

(Personally, I don't see why the content server can't evaluate the ACL
itself. But that just proves that if we do try to spec the CS<->AS protocol,
it'll slow down the client->server protocol finalization.)

> 2) Could re-directed authentication be layered on top of the existing
> schemes so that it could be used with basic, digest, and X.509?
Re-directed authentication is totally transparent to the client, so talking
about "on top of existing schemes" is not meaningful.

Received on Saturday, 13 December 1997 11:54:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:29 UTC