Re: Access Control Draft

Yaron Goland wrote:
> 
> I would add
> 3) how does an author DISCOVER the access policy of a resource
> 4) how are principals identified
> 
> BTW a forms based solution is not sufficient. As specified in the design
> principals, all DAV mechanisms must be fully machine processable. HTML
> forms do not meet this definition. Still, simpler is better. We don't
> need to solve the world's problems, we just need to solve DAV's problems
> in such a way that others can come along later and build upon our work
> to solve the world's problems.
> 
>                 Yaron

I think we're agreeing but I'm not sure. Policies are resources. One way
of accessing a resource is through forms. It might be the only common
mechanism of actually operating on the policy, but DAV itself doesn't
need
to operate on policy.

A policy resource could export multiple interfaces, one that was generic
and form-based, and another that was specialized and 'fully machine
processable'. (I think that, beyond 'fully machine processable', 
'standardized and uniform' is also a requirement; if different systems
have different 'machine processable' interfaces, it doesn't help
interoperability.)

I think the issues of separating policy discovery from policy
manipulation
are common between WEB DAV and other protocols. I was thinking about
access control for Web Printing, where the policy of access control
are varied and site dependent ("students account holders are not allowed
to use the transparency tray except between 9 am and 5 pm"), yet
a generic client (print driver) might need to interact with the service
provider to discover policy options, and a system administrator might
need to set policy options. I've been spending too much time thinking
about IPP.

Larry


> > -----Original Message-----
> > From: Larry Masinter [SMTP:masinter@parc.xerox.com]
> > Sent: Friday, May 16, 1997 3:54 PM
> > To:   Jim Whitehead
> > Cc:   w3c-dist-auth@w3.org
> > Subject:      Re: Access Control Draft
> >
> > I actually thought that you could ignore access control completely
> > except for two things:
> >
> > 1) how does an author CHANGE the access policy of a resource
> > 2) how does an author SPECIFY the access policy of a new resource
> >
> > and that (2) could be defined as
> >    Inherit the default access policy and then do (1)
> >    (There's an unfortunate window when items have the wrong
> >     access policy).
> >
> > However, it should be possible to do (1) and (2) for a wide
> > range of different kinds of access policies.
> >
> > It might be that every resource has a related linked resource
> > which is its access policy, and that the access policy could
> > be retrieved as text/html (in which case you would get a form
> > that would allow you to modify it, if you were so authorized)
> > or as some other representation (which a program that was
> > knowledgable about the structure of access policies on the
> > particular server would be able to directly manipulate it).
> >
> > It might be that access policies should be linked to 'realms'
> > rather than 'resources' where a 'realm' was some well-defined
> > extension set of resources.
> >
> > I'm not sure how the discussion got off into APIs and CORBA,
> > though.
> >
> > Larry
> > --
> > http://www.parc.xerox.com/masinter
> >

Received on Monday, 19 May 1997 23:39:29 UTC