IF_AND_AUTH: This issue was raised by Geoff.

LOCK_SEMANTICS:  This was apparently raised by the DeltaV design team.


Julian, your recommended solution goes counter to the solution
recommended by the people who raised these issues, as far as I can
tell. Both these issues were raised in order to strengthen the
requirement that authentication is required to use a lock
token, whereas you suggest loosening that requirement altogether.


So, with conflicting suggestions, we need more discussion and for
people to indicate which side they fall on.   

 1. Authentication is required for lock token usage but the draft is
clear enough already.

 2. Authentication is required for lock token usage but the draft
needs clearer text (please suggest where, what text).

 3. Authentication MAY be required for lock token usage (see text
below).

 4. Other -- please describe your position.


This is a call for consensus -- I'll respond separately with my own
opinion. 


For reference, here are the most salient sections of the existing -bis
draft:


section 6.3:

"<fixed><fontfamily><param>Courier New</param><smaller>Having a lock
token provides no special access rights. Anyone can find out anyone
else's lock token by performing lock discovery. Locks MUST be enforced
based upon whatever authentication mechanism is used by the server,
not based on the secrecy of the token values."</smaller></fontfamily></fixed>


section 7.6 the "authorized" is re-emphasized:

<fixed><fontfamily><param>Courier New</param><smaller>In order to
prevent these collisions a lock token MUST be submitted by an
authorized principal for all locked resources that a method may change
or the method MUST fail.  </smaller></fontfamily></fixed>


Here's some proposed text to consider adding to section 7.6  if we
lean towards option 3 above (note this would also require changing the
text in the above quoted paragraphs):


<fixed><fontfamily><param>Courier New</param>Servers MAY restrict
usage of the lock token to exactly the authenticated principal who
created the lock.  Servers MAY also allow other privileged
authenticated principals or even unauthenticated principals to use the
lock token. </fontfamily></fixed>


Lisa


On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:


<excerpt>

From <<http://www.webdav.org/wg/rfcdev/issues.htm>:


IF_AND_AUTH: "The fact that use of authentication credentials with
submission of lock tokens is required should be strengthened in the
document."


and


LOCK_SEMANTICS: "At present, the WebDAV specification is not
excruciatingly explicit that writing to a locked resource requires the
combination of the lock token, plus an authentication principal. At
one point, the spec. discusses an “authorized” principal, but
“authorized” is never explicitly defined."


I'd like to confirm that indeed authentication and the ability to use
a given lock token MAY be orthogonal. That is, a server can


- restrict usage of the lock token to exactly the principal that was
authenticated when the lock was obtained,


- restrict usage to the creator as above and a group of other
principals that are allowed to "break" the lock (WebDAV ACL DAV:unlock
privilege, see
<<http://greenbytes.de/tech/webdav/draft-ietf-webdav-acl-latest.html#PRIVILEGE_unlock>)
or


- allow anybody who knows the lock token to use it.


I think right now there are servers implementing each of these
schemes, and there doesn't seem to be any problem with that.


Regards, Julian


-- 

<<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


</excerpt>