Re: Access Control Draft

The reason an API based approached was initially suggested was
to provide a mechanism through which server-based applications
which act as "receivers" for requests from the client could have
a standardized mechanism for asking the environment whether the
user has a particular permission.

There are some precedents within the IETF/RFC community for APIs,
namely GSS-API (A security API, not related specifically to
permissions).

The CGI standard effectively implements an API by defining
environment variables as a mechanism for passing information
between the server and forked processes.

In addition, it might be possible to develop an API that is
language neutral by using a technology such as CORBA.  The
principal drawback there is the lack of extensive CORBA
deployment and the additional overhead associated with using
it.

Permissions are essentially a "server" technology.  It is unclear
to me what information regarding permissions would ever be
transacted between the client and the Web server, other than
perhaps a denial-of-access response (which is already handled
in the HTTP 1.0 spec).  In addition, the predominant leaning so
far from everyone has been that a spec that governs the creation
and management of permissions is out of scope.  That leaves us with
the issue of resolving what a particular user can or can't do.

Any comments on the above?

Received on Thursday, 15 May 1997 19:11:11 UTC