W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

Re: Interop issue: how can clients force authentication?

From: Dan Brotsky <dbrotsky@adobe.com>
Date: Wed, 16 Oct 2002 08:50:45 -0700
Cc: Dan Brotsky <dbrotsky@adobe.com>
To: w3c-dist-auth@w3.org
Message-Id: <08815398-E11F-11D6-8202-0003931036B4@adobe.com>

As usual, sorry for letting so much time pass before jumping in.

On Friday, September 20, 2002, at 05:39 AM, Clemm, Geoff wrote:
> I believe the problem statement is:
> The problem: A client wants to check if the current user is
> authenticated to do an operation before it has that user provide the
> input for that operation, and before it performs expensive
> computations to set up the input for that request.

Almost.  As you can see from my other message, I believe it's actually 

The problem: Before starting a sequence of requests on a resource, a 
client wants to ensure that it is authenticated as a principal who is 
authorized to perform all the various methods in the sequence.  If it 
is not so authenticated, it wants to be rechallenged so it can 

> The proposal: Document in the 2518bis that the authentication check
> SHOULD be performed before the If header check (so that a simple
> contradictory If header can be used to check the authentication for
> "dummy version" of the operation, i.e. one with dummy values that did
> not require user input or expensive calculations on the client).

Unfortunately this (a) doesn't allow checking for a number of different 
methods in a single call, and (b) doesn't require the server to check 
authorization, just authentication.  What's wanted is for the server to 
return 401 unless the user is actually authorized to perform all those 
methods, not simply authenticated.  I don't believe it's actually 
reasonable to require servers to perform authorization checks before 
they perform IF checks (consider that IF checks may be much cheaper to 
perform than going to some back-end LDAP database to get ACL info).  In 
addition, many servers are going to want to simply return 403 to the 
request (indicating that the current user is not authorized for that) 
rather than to re-challenge, which is what the client wants to happen.

I'm afraid that the extensive discussion around this is causing me to 
believe that it's beyond the scope of what we can cover in 2518-bis, 
and quite possibly what we can cover in any extension of DAV.  But 
there's a proposal of Julian's (do PROPPATCH on a specially known live 
property) that I believe has some chance of doing what we want, and 
I'll send another message with just that revised proposal.

Received on Wednesday, 16 October 2002 11:51:26 UTC

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