List Info

Thread: WGLC on Common Policy




WGLC on Common Policy
user name
2006-02-21 22:09:35
On Feb 20, 2006, at 12:39 PM, Allison Mankin wrote:
>
> We are starting the WGLC on
draft-ietf-geopriv-common-policy-07.txt

The principle of only adding permissions rather than ever
withdrawing 
them, which is clearly stated in section 4, and for which we
had 
compelling reason during WG discussions appears to be
violated by 
allowing a large and possibly unknown number of users in
section 7.1.4. 
  Despite the promise toward the end of section 4 "No
all-except 
conditions", section 7.1.4 does neither justifies this
violation nor 
explains how the apparent violation of principle is not a
violation 
"how exceptions can be made to work".  Rather,
it simply specifies that 
exceptions are allowed in the important case of user
identities.  My 
impression was that either the justification would be
included or the 
exception feature would be excluded.

John

Relevant text for convenience:

4.  Goals and Assumptions
...
    Permit only:

       Rules only provide permissions rather than denying
them.  Allowing
       both 'permit' and 'deny' actions would require
some rule ordering
       which had implications on the update operations
executed on these
       rules.  Additionally it would make distributed rule
sets more
       complicated.  Hence, only 'permit' actions are
allowed which
       result in more efficient rule processing.  This also
implies that
       rule ordering is not important.  Consequently, to
make a policy
       decision requires processing all policy rules.

...
    No all-except conditions:

       It is not possible to express exclusion conditions
based on
       identities such as "everybody except
Alice".  However, this
       restriction does not prevent all forms of
blacklisting.  It is
       still possible to express an authorization rule like
'I allow
       access to my location information for everyone of
domain
       example.com except for John'.  See the example in
Section 7.1
       describing how exceptions can be made to work.  The
reason for
       this choice is the ease with which identities can be
manufactured,
       and the implication that all-except types of rules
are easily
       subverted.
...

7.1.4.  Matching Multiple Entities

    The <many> element is a mechanism to perform
authorization decisions
    based on the domain part of the authenticated identity. 
As such, it
    allows to match a large and possibly unknown number of
users within a
    domain.

    Furthermore, it is possible to include one or multiple
<except>
    elements to exclude either individual users or users
belonging to a
    specific domain.  Excluding individual entities is
implemented using
    a <except id="..."/> statement.  The
semantic of the 'id' attribute
    of the <except> element has the same meaning as
the 'id' attribute of

    the <one> element (see Section 7.1.3).  Excluding
users belonging to
    a specific domain is implemented using the <except
domain="..."/>
    element that excludes any user from the indicated
domain.

    If multiple <except> elements are listed as child
elements of the
    <many> element then the result of each
<except> element is combined
    using a logical OR.

_______________________________________________
Geopriv mailing list
Geoprivietf.org
https:
//www1.ietf.org/mailman/listinfo/geopriv
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )