- From: Clemm, Geoff <gclemm@rational.com>
- Date: 2002年1月10日 23:42:49 -0500
- To: w3c-dist-auth@w3c.org
- Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E1353@SUS-MA1IT01>
From: Daniel Brotsky [mailto:dbrotsky@adobe.com] I think there are a variety of client needs here. These are probably a little too fuzzy to be called requirements :^), but it's the best I can do right now. 1. This came up at the first interop, and most servers seemed to be compliant by the second interop: The <owner> part of a lock is to be completely controlled by the client. The server MUST not alter it (i.e., lock discovery, if it returns the <owner> information, must return exactly equivalent XML to that in the LOCK request). There's a lot of discussion of why this is needed in the archives; the gist is that it's the only client-controlled XML that's always associated with a LOCK, so clients of a given ilk can use it to exchange conventional information with each other about the lock. I agree. 2. There's some well-known specification of "principal" in the sense of "authenticated user ID whose authorization is being used for the current request." Probably this is a string of some kind, and probably there are localization issues so we will want this string to be in a known encoding (e.g., UTF-8) or else all mechanisms that return this string must be able to return the encoding. In general, the user will not map 1-1 with a "principal", but rather a user will "match" one or more principals. Therefore I do not see that it is feasible or desireable to try to identify a particular principal for the current user. 3. Clients need to know/be able to discover which "principal" they are. I don't really know enough about the range of authentication schemes to understand whether clients can always know for sure what "principal" the server is associating with them based on the client-generated authentication header, or whether the client might simply have been given some set of opaque credentials and need the server to tell it which "principal" those credentials make it. I believe this is the same as (2), and the same counter-arguments apply. 4. Clients need to know/be able to discover which "principal" owns a given lock, that is, which principal made the original lock request. We did agree in an earlier thread that a "DAV:can-lock" and a "DAV:can-unlock" privilege should be supported, so that an ACL can indicate who can lock or unlock a resource. But I disagree that it is necessary or useful to identify a principal that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock ACL that matters, and that is not determinable from the "principal" that created the lock. 5. Clients need to know/be able to discover where the "root resource" of a lock is; that is, the resource on which the lock owner can do an UNLOCK of the right depth and get the lock released. I agree. So my set of requirements would be: A) The DAV:owner field of the lock is under client control. B) A DAV:can-lock and DAV:can-unlock privilege should be defined. C) The root resource of a lock should be discoverable.
Received on Thursday, 10 January 2002 23:43:51 UTC