RE: comments on access control requirements

Section 2.0 - Introduction
"Native operating system methodsare ineffective because the users
responsible for modifyinginformation on the Web site are generally not
logged ininteractively to the server in a manner that maps their
identityto a local user-id."
While I am aware of systems, such as FrontPage, which create user-ids
that only exist for FrontPage and not the underlying system, the
majority of web servers I am familiar with map web based authentication
directly to user IDs. The use of the clear text password challenge is
often used to map users to their UNIX Ids and the use of NTLM is widely
used in NT environments to map users to their accounts. I think the next
sentence, regarding different types of ACL systems is strong enough to
justify the existence of this draft, the sentence quoted above is not,
in my opinion, needed.

"The "htaccess" file utilized on many Web Servers todaydeals principally
with read permission, and is unsuitable for themore complex access
control issues that exist in the distributedauthoring environment."
Howard, I second your comment that this sentence is dated and should be
removed.

"This document describes requirements for a set of methods which could
be implemented within the framework of the proposedHTTP standard for the
following:"
Howard, I second your comment that the word "methods" should be changed
to "mechanisms". One of the lessons we learned from our work on the DAV
requirements document is that a good requirements document does not
proscribe how something is achieved, only the requirement that it be
achieved.

": Creation and modification of security policies: Assignment of
security policies to resources: Querying for policy information on a
resource: Types of standard access control types"

Howard, I agree with your comment that having a list such as the one
above is a good thing. However I have some serious reservations about
the definitions of the term "security policies". That issue is further
addressed below.

Section 3 - Terminology

I think the term principal should be defined in DAV and, at best,
repeated verbatim in the ACL draft. I also believe a definition should
be provided for both policy and ACL. As I have learned talking to
different folks about security there are a lot of subtle differences in
the way people use security terms. For example I use the word ACL in a
way that most folks use the word ACE. Also, I agree with your comments
that we will have to require the definition of some sort of
extensibility mechanism along with some basic access controls. I believe
you are dead on when you say that just passing around blobs that will
get defined at some point in the future buys us nothing.

This having been said I would like to see the terms Application and
Server Based Application both stricken from the terminology section. The
definitions aren't, in my opinion, useful.

Section 4 - General Principles

I agree that this section requires significant work.

Also, URLs are generally opaque to clients. Servers spit them out,
clients just move them around. I suggest we follow the same rule when it
comes to identifying principals. The requirement document should not
require that principals can generate or even dissect principal
identifiers. Rather I suggest we intentionally leave undefined how it is
a principal comes into possession of a principal identifier.

In fact I would suggest we stick to the agreements made at the Orem
meeting that the DAV ACL mechanism would ignore issues of how principal
identifiers are created or what they represent and instead define what a
principal can do once they have such an identifier and the authorization
to use it.

Section 5.1 - Setting of Access 


Not to be picky but can we please use the word "control" instead of
"constraints"? I believe the later to be common usage. We also need a
very detailed definition of what an access control is. Otherwise, we
don't know what it is we are requiring.

Section 5.2 - Inheritance

I am not clear as to what problem is introduced into the protocol by
lazy inheritance. Inheritance is a mechanism to specify ACL information
for resources within a certain scope. If a resource is available in the
scope, regardless of how it got there, then it is expected to have the
specified ACL information. So, examining the situation strictly from the
view "on the wire" there is no discernable difference between lazy and
normal inheritance. As such we should be able to specify them the same
way.

Either way I do not believe we can escape inheritance. Just about every
ACL system I am aware of, from UNIX to the high end document management
servers support inheritance as a way for someone to allow controlled
access to creation capabilities within their namespace.

Section 5.3 - Reporting to Server-Based Applications


I believe this section is inappropriate to a protocol requirements
document and should be removed. We are dealing strictly with the
protocol definition and the expected behaviors from the commands passed
through that protocol. How those behaviors get enforced on the server is
out of scope for both the requirements and the protocol.

Section 5.4 - Access Control [Judy: for Access Constraints]


Ahh the snake biting its own tail. I would recommend that the
requirements only state that there be a way to control who has the right
to change access controls. The actual form of that mechanism should be
left to the protocol group.

Section 5.5 - Standard Access Attributes


While I think it is appropriate for the requirements document to mandate
that some set of rights MUST be supported by all servers I additional
believe that we need to make it clear that it is up to the protocol to
decide how to group these rights. For example we may create a "list"
right which provides both the rights Judy lists in section 5.5.2 rather
then two separate rights. The final decision should remain with the
protocol designers.

Section 5.6 - Discovery


"Plain"? I think that term is inappropriate. I believe the requirements
document should restrict itself to specify that discovery must be
possible through a mechanism that is capable of producing machine
processable output. Human readable descriptions, in my experience,
actually hinder rather than help interoperability. A goal referenced
several times through out the ACL requirements document is the desire to
have webdav tools be able to interact with multiple systems. It is only
by carefully defining every word and utterance that these tools can be
sure of providing their users of a consistent, well defined, experience.
When we start to require 'Human readable' viewing then we remove the
ability for the tool to frame the user's experience and we hinder the
cause of interoperability as natural language is significantly less well
defined than a well defined schema. Additional requiring a "human
readable" view for webdav compliant devices that engage exclusively in
machine to machine community, such as a printer on a network, is
inappropriate.

Over all I find myself in general agreement with Howard's comments.

				Yaron









> -----Original Message-----
> From:	hep@netscape.com [SMTP:hep@netscape.com]
> Sent:	Thursday, October 09, 1997 9:50 AM
> To:	w3c-dist-auth@w3.org
> Subject:	comments on access control requirements
> 
> Attached is an annotated copy of the access requirements draft, with
> Judy's changes, and my comments.  This document is also available as: 
>   Howard's Comments on Requirements
> <http://people.netscape.com/hep/webdav/ac/acreq-hp.html>  
> Howard 
>   << File: acreq-hp.html >>

Received on Saturday, 11 October 1997 01:32:15 UTC