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


> ----------
> 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
possible.

(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.

Paul
Received on Saturday, 13 December 1997 11:54:18 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:05 EDT