Re: Revised Access Authorization Spec

• Mail folder: WWW Talk Jul-Oct 1993
• Next message: Dave_Raggett: "Re: HELP: Running X/Mosaic from behind a firewall "
• Previous message: Steve Heaney: "Re: Access Authorization"

Date: Fri, 17 Sep 93 10:34:45 +0200
From: luotonen@ptsun00.cern.ch (Ari Luotonen)
Message-id: <9309170834.AA07568@ptsun00.cern.ch>
To: www-talk@nxoc01.cern.ch
Subject: Re: Revised Access Authorization Spec
Status: RO

> >  * A given server supports a fixed set of authentication schemes, i.e.
> >    this set may not vary according to which ducument is being
> >    accessed. Otherwise this would complicate either rule or ACL file.
> I don't think this should be a general restriction.  Plexus will have
> no problem doing this and configuration doesn't have to be unduly
> complicated (e.g., you could simply put the config file in each top-level
> directory instead of having a central one).

Top-level directory is not good (the same reason as before, links in file
system). But I have changed my opinion, I agree; how about changing
"protect" rule (because it has already become 90% redundant -- don't ask
me how I get these figures... ;-)):

	protect <template>
	protect <template> <authentication>
	protect <template> <authentication> <protection>

<authentication> is something like "basic", "pubkey", "Kerberos", etc.
<protection> is something like "NONE", "MIC-ONLY", "ENCRYPT".

And there would also be two additional fields in rule file:

	default_authentication <authentication>
	default_protection <protection>

Which are used if <authentication> and/or <protection> is not provided
in "protect" rule, or if there is no "protect" but there is an existing
ALC file.


> >  * A reply from a protected server starts with a status line:
> > 
> > 	HTTP/1.0 202 Privacy enhanced reply follows
> Why define a new code?  IMHO, all this information should be in headers,
> not on the status line.  You even already defined headers for this, so
> this is really just duplicate information.  Does it really serve any
> purpose?

Well now that I think about it, it doesn't serve any purpose. Ok, it's
going bye-bye.


> Oh, BTW, TimBL had suggested using WWW-foo: for the new headers we define
> to avoid collisions.  Of course, any headers you are using from existing
> specs or proposals are fine.

Ok, so they will be:

Both:
	WWW-Body-MIC:		These could be only one MIC-Info: with
	WWW-Header-MIC:		multiple subfields. How about it?

Request:
	Authorization:		This is already in use, and was in HTTP spec
				when I started on this, so no "WWW-".
Reply:
	WWW-Authenticate:
	WWW-Protection-Template:
	Key-Info:		These
	DEK-Info:		two are like in PEM.


-- Ari --