RE: Access Control: What's On The Wire

This might just be a more direct way of saying what you are saying.

I think you will find that the only way to specify that credentials should be sent without restricting the implementation to any particular method (X.509, kerberos...) is to define a "credential cookie" which the client sends to the server.

Determining which form of credential to send (assuming the client has a choice) would require the client and/or the server to send a list of the supported credential "formats" in order of preference the one being used being the highest commonly supported format (credential handshake).

This implies that the minimum that this WG is going to have to do is

1)  Decide which schemes we regard as candidates for credentials
2)  Determine the extension to HTTP for the credential handshaking explicitly naming the identified credential schemes and such that it can be extended to support other schemes (similar to the MIME-type names)
3)  Determine the extension to HTTP for the credential cookie transfer

Cheers
Dylan

----------
From:  Fisher Mark[SMTP:FisherM@exch1.indy.tce.com]
Sent:  Mittwoch, 28. Mai 1997 22:39
To:  'w3c-dist-auth'
Subject:  Access Control: What's On The Wire

The big question to me in WebDAV access control is, "What should go over
the wire?".  I see 3 things that go from the client to server:
	1) An HTTP method;
	2) Credentials identifying the client; and
	3) One (or more) URIs identifying the resource.
The server then responds with a status code, along with a Reason-Phrase.

Now, credentials can be several things.  The simplest non-null case is a
single ID.  If you are in a relatively high-trust situation (like inside
a company Intranet), merely tracking the author by ID may be sufficient.
 Or, for somewhat greater security, a one-time ID (like a SecurID
without the PIN), may be adequate in some cases.  UserID/passwords are
quite commonly used in multiuser OSes, while X509 certificates and
signed PGP messages both have their advocates.  What goes over the wire
from the client to server, however, are HTTP-method + credentials +
URI(s).

Since WebDAV is an extension for HTTP, any credential-sending mechanism
(authentication method) considered by this group should be via HTTP.
This is not to preclude other authentication methods (CORBA, Kerberos,
etc.) being used, it is just to say that non-HTTP methods are likely out
of this group's scope.  This is also not to say that adding
authentication mechanisms to HTTP should not be considered, as work done
on additional authentication mechanisms would benefit Web users as a
whole.

To make a long story short (too late! :( ), what WebDAV access control
needs to be concerned with are the HTTP authentication methods to
support, the HTTP methods needed for WebDAV, and the HTTP status
responses.  Although there will be clients and servers that use DCE,
NTLM/CIFS, etc. for access control, since they are not using HTTP, IMHO
we should not be spending our time on this mailing list considering
these options.
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
fisherm@indy.tce.com          Indianapolis, IN
"ViaCrypt?  Vhy not!"

Received on Thursday, 29 May 1997 07:37:24 UTC