W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004


From: Lisa Dusseault <lisa@osafoundation.org>
Date: Wed, 28 Apr 2004 11:07:29 -0700
Message-Id: <E9D31D0F-993E-11D8-B566-000A95B2BB72@osafoundation.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Webdav WG <w3c-dist-auth@w3c.org>
To: Lisa Dusseault <lisa@osafoundation.org>
So for the record, I lean towards option 1 (no change) because I can't  
recall any interoperability problems in this area.  Without any known  
interoperability problems, it seems safest to leave the spec unchanged.


On Apr 28, 2004, at 11:00 AM, Lisa Dusseault wrote:

> 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:
> "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."
> section 7.6 the "authorized" is re-emphasized:
> 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.
> 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):
> 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.
> Lisa
> On Apr 25, 2004, at 8:00 AM, Julian Reschke wrote:
>> 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

Received on Wednesday, 28 April 2004 14:08:19 UTC

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