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

RE: Access Control Draft

From: Dylan Barrell <dbarrell@opentext.ch>
Date: Fri, 16 May 1997 10:18:43 +-200
Message-ID: <01BC61E2.8939C8E0@cassius.opentext.ch>
To: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
For me the real reason why we don't want to specify an API for this is that API's are the client/server way of doing things and protocols are the Web way of doing things - i.e. let's keep it consistent.

We should however specify and API whereby the access control can be provided by a third party application (server extension) on the server side thereby relieving the server providers from the necessity of providing the functionality (they only have to support the API).


From:  Jon Radoff[SMTP:jradoff@novalink.com]
Sent:  Freitag, 16. Mai 1997 01:15
To:  Gregory J. Woodhouse
Cc:  w3c-dist-auth@w3.org
Subject:  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

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

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 Friday, 16 May 1997 04:20:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC