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:52:19 -0700
Cc: Dan Brotsky <dbrotsky@adobe.com>
To: w3c-dist-auth@w3.org
Message-Id: <4073DA40-E11F-11D6-8202-0003931036B4@adobe.com>

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 (with thanks but no blame to Julian): The client sends a 
(probably unauthorized) request to PROPPATCH the DAV:authorized-methods 
property of the resource with an methods element containing a 
checkauthorization element and elements for each of the methods it 
wishes to use.

   <!ELEMENT methods (checkauthorization? options? get? put? mkcol? 
lock? ...) >
   <!ELEMENT checkauthorization EMPTY >
   <!ELEMENT options EMPTY >
   <!ELEMENT get EMPTY >
   (extra credit: guess who desperately needs Julian, Stefan, and Geoff 
to fix his XML...)

In the wonderfully-future-compliant case: the server actually looks at 
the value of the property specified, and continues to challenge (401) 
the client until the client authenticates as a user who is actually 
authorized to perform all those methods on that resource.  At that 
point the server return 409 because (ha!) DAV:authorized-methods is 
actually a read-only property.

In the currently compliant server case: the server just 
authenticates/authorizes the user for the PROPPATCH on the resource, 
and then either sets the (dead) property or refuses the request (403, 
presumably), because the user is trying to set a property in the DAV: 
space that's not mentioned in the current version of the spec. :^)


PROPOSED LANGUAGE (first shot, sort of):

- Define the property DAV:authorized-methods as a live property whose 
value is a methods element.

- A server SHOULD return, as the result of a PROPFIND on 
DAV:authorized-methods, EITHER the set of methods that the requesting 
principal is authorized for over that resource OR 404 Not Found 
(meaning the server doesn't want to or is unable to tell you).

- A server MAY treat DAV:authorized-methods as a dead property (for 
backward compatibility).

- If a client attempts to PROPPATCH the value of 
DAV:authorized-methods, it MUST use a checkauthorization element as the 
first member of the property, and it MUST include all the methods that 
it want to check authorization for.

- Servers SHOULD respond to client attempts to PROPPATCH the value of 
DAV:authorized-methods by responding with 401 until the client 
authenticates as a principal authorized to perform all such methods on 
the target resource (if there were a target resource).

- Servers MAY respond to client attempts to PROPPATCH the value of 
DAV:authorized-methods as if DAV:authorized-methods were a dead 


Some impressions and issues:

1. Sheesh.  What a hack.  But at least it covers the fairly common case 
of servers that authorize LOCK, PUT, PROPPATCH, UNLOCK (and usually 
DELETE) the same way.  Those servers just treat the new property as 
dead, and clients get what they want.

2. What exactly happens if you PROPPATCH an URL that's not bound to a 
resource, anyway?  That's going to be a very common case if you were 
planning to LOCK the resource first, and you probably don't want the 
server creating the resource on the PROPPATCH.

OK, folks, have at it! :^)

Received on Wednesday, 16 October 2002 11:52:54 UTC

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