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

Re: Issue 71, Clarify what servers may and may not do with privileges when BIND is used (was: Moving forward on BIND)

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 26 Apr 2005 23:03:04 -0400
To: Elias Sinderson <elias@cse.ucsc.edu>
Cc: Julian Reschke <julian.reschke@gmx.de>, "'webdav'" <w3c-dist-auth@w3.org>, w3c-dist-auth-request@w3.org
Message-ID: <OF5276A87B.FCBA8F3B-ON85256FF0.00105D46-85256FF0.0010C313@us.ibm.com>

I don't quite follow what you are suggesting here.  To make this
more concrete, what additional language do you think needs to be
added to the method or properties being defined in the binding spec?


Elias wrote on 04/26/2005 05:21:35 PM:
> Julian Reschke wrote:
> > [...] most of the open Bugzilla issues should have been closed [...]
> 71, Clarify what servers may and may not do with privileges when BIND is 

> used
> As ACLs are defined on resources, not bindings, I don't see how the spec 

> can say much that hasn't already been said. There are, however, 
> potential issues with bindings across different security domains. If 
> anything, I would advocate a restrictive approach to permissions. That 
> is, permissions on bindings SHOULD default to those of the resource 
> where possible, but MAY be restricted when bindings are made across 
> namespaces with different permissions. Permissions MUST NOT be granted 
> or extended in the above scenario. As I see it, this is the prudent 
> thing to do in this situation. The only other option would be to forbid 
> bindings across security domains that cannot maintain the existing 
> permissions exactly as they are on the resource (if, for example, a 
> given principledid not exist and could not be created).
> Comments?
> Best,
> Elias
Received on Wednesday, 27 April 2005 03:03:18 UTC

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