- From: Paul Leach <paulle@microsoft.com>
- Date: Thu, 11 Dec 1997 19:11:54 -0800
- 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 UTC