I agree with all except I believe we should evaluate which authentication schemes we consider important and ensure that WebDAV can support them. I think X.500 with X.509 is a good candidate for evaluation. It is also my belief that we have an opportunity to specify HOW a web server interacts with a authentication server and should seize this opportunity now - it might never come our way again.
Are there any representatives from the two large HTTP server providers (Microsoft or Netscape) participating on this listserver?
Cheers
Dylan
----------
From: Jon Radoff[SMTP:jradoff@novalink.com]
Sent: Dienstag, 20. Mai 1997 18:00
To: Larry Masinter
Cc: w3c-dist-auth@w3.org
Subject: Re: Access Control Draft
I really like the "policy" based approach. It could also provide
a fairly transparent layer from which could interface with
implementation specific access permissions.
Here is an outline for some of what might be included in this
type of design:
1) A "security policy" resource, which is identified by a
token string established by the Web server's administrator.
This security policy resource is implementation-specific, and
not defined by WEBDAV. The purpose of WEBDAV in this part
is principally to define how you name and interact with
these policy resources.
2) A standardized protocol -- either an HTTP extension, a forms-based
approach, an extension to the URL invocation convention, etc.,
which is capable of a assigning a named security policy to a
named object. (An object in this context means a particular
thing you can access via the Web, for example, an HTML document,
a JPEG image, a Java applet, etc.)
3) In addition, we could also define "methods" which are associated
with a given resource. For example, we could identify the
"read" method for an object, and then assign a particular policy
to this method for a particular object. "Modify" and "delete"
might be other standard methods. Under this theory, we
could also support the object model and inheritance by
associating policies with classes of objects -- for example,
all "HTML Objects" have such-and-such policy, all "HTML Objects
in the Marketing Site" either inherit this policy or have their
own definition. If any of these things are favored, we need
to determine what we specify as standard or recommend insofar
as (a) standard method naming conventions, (b) whether the
object model is directly support in the protocol or whether this
is implementation specific.
The server implementation would be responsible for interpreting
the policies, matching them up with resources, authenticating the
user and matching up this information to associate it with
local policy. Vendors can decide how they want to work with
policy resources -- some might want this to be administered through
forms, others through special client software, etc. I don't
think this would be important to what we recommend.
It seems that this approach provides a lot of growth potential.
This also allows for development of standardized APIs outside of
this particular specification. For example, after the initial
protocols for this are determined someone could identify a
CORBA encapsulationg mechanism for modifying security policy
resources.
Jon