Re: Access Control Draft

Howard Modell wrote:

>{snip} ... one of the
>things that comes up is that a Web document not only has a
>list of authors, but an "information owner" as well who might not
>*be* an author, but *is* responsible for what goes into the document.
>
>Thus, I can see access control information specifying not only a list
>of authorized authors/editors, but the Information-owner as well (who
>may need to approve changes).
>
>Conceivably, one might even need to account for the web-server administrator
>who may be the only person allowed to (re)place documents in the server's
>directories (analogous to the "mailing listserver administrator").

It seems to me that what you're edging towards is an access control scheme
with a set of roles (e.g. author, approver, publisher, etc.), with each
role having separate access rights (e.g., an author may get/put, but not
move/copy, while a publisher may move/copy but not put).

While I have seen systems which use such an approach (e.g. Continuus/CM),
there are some drawbacks. One difficulty is the definition of a canonical
set of roles. In order to define a role, you have to define the process in
which that role participates.  In the post above, there is an assumption of
a process in which the work of authors is approved by some other principal.
However, while this is a common case, it is by no means pervasive.  For
example, I require no approval to publish my personal Web pages, while
other sites require several approvals prior to publishing.

I think it should be possible to support a role-based access control
scheme, but I don't think the actual access control scheme should hardwire
a set of roles, or a particular authoring process.  It is far better to
develop a set of primitives which can be used to implement a wide range of
access control policies, and hence allow a workflow/process enactment
system to be built using these primitives.

- Jim

Received on Monday, 19 May 1997 16:07:23 UTC