Re: Access Control Draft

Hi,
Most of the issues here are related to the interface defination by WEBDAV. I
am trying to understand if we ought to specify the interface definition (
and may be some of the implementation specific semantics ). If that is the
case then I am in complete agreement with the suggestions made out here.
     The issue of policy based approach is fine but I feel that will
overload the generic approach of the specifications.  However, I am of the
agreement that some amount of help has to be provided to the tool developers
in terms of building their tools and applications based on the
specification. I would like to understand how we could provide a
specification which is very generic and has no implementation bais within
it, at the same time how to make the specification useful. Most of the time
specs are either so generic that they are not useful or they are to specific
for every individual implementation such that two different tool developers
develop their application on the same specs but they are worlds apart in
their approach.




>>> Larry Masinter <masinter@parc.xerox.com> 05/20/97 01:55PM >>>
Jon Radoff wrote:
> 
> 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.

Different editable resources might might have different policies
associated with them, and the difference might not be 'server'
based. Designs that go from 'attribute of server' to 'attribute
of resources served by the server' aren't scalable.

As for how to identify a resource, it's useful to use a uniform
resource identifier, aka "URI", rather than "a token string
established by the Web server's administrator", since of course
the server itself might generate such a thing without the
administrator's actions.

WEBDAV need not be involved in the naming of policy resources, unless
you mean the location of them, and might not need to specify
the interaction with them, other than that they're network resources
to be interacted with using the web.


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

An individual policy ("students cannot check in changes to their
grades but can check in changes to their home address") has a structure
("class X of users can/cannot make change Y to part P of resource V").
A policy structure might have a "name" before it is assigned to a 
resource, but in general, a particular instance, like any other kind
of metadata, may not exist outside of the resource to which it applies.
I think the standard way of associating access policies should be the
same as the standard way of associating other kinds of metadata.

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

In general, the structure of access policies are fine grained
enough in some situations that they may not be determinable 
a priori While it's useful to have the precondition ("how would
you react if I tried to change my grade?") or even the elimiation
of all actions in a given class ("can user X change the metadata
of resource V"), I don't think the protocol should require that
the access policy fit the general case in order to have an efficient
and simple implementation.

> 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

-- 

Larry

Received on Wednesday, 21 May 1997 16:14:39 UTC