W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: Daniel Brotsky <dbrotsky@adobe.com>
Date: Tue, 8 Jan 2002 22:18:23 -0800
Message-Id: <p0510100eb8618e218fdd@[153.32.158.166]>
To: "Jason Crawford" <ccjason@us.ibm.com>
Cc: w3c-dist-auth@w3c.org
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.

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.

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.

4. Clients need to know/be able to discover which "principal" owns a 
given lock, that is, which principal made the original lock request.

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.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Wednesday, 9 January 2002 01:18:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT