- From: Dan Brotsky <dbrotsky@adobe.com>
- Date: Wed, 16 Oct 2002 08:52:19 -0700
- To: w3c-dist-auth@w3.org
- Cc: Dan Brotsky <dbrotsky@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
reauthenticate.
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
property.
----------
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! :^)
dan
Received on Wednesday, 16 October 2002 11:52:54 UTC