W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1997

Re: Access Control Draft

From: Jon Radoff <jradoff@novalink.com>
Date: Thu, 15 May 1997 19:15:05 -0400
Message-ID: <337B98F9.565@novalink.com>
To: "Gregory J. Woodhouse" <gjw@wnetc.com>
CC: w3c-dist-auth@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT