RE: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Naoko ITO ^lt;naoko_i@mva.biglobe.ne.jp>
Date: Fri Nov 07 2003 - 22:04:58 EST

Hello Henning,

Thank you for your reply.
Comments in-line.

> It is not exactly a black list, although it can be used for that.
> That's why I called it an exception list.

Sorry, I was not (and am not) very careful about choosing words.
I understand a black list is one of the application of exception list.
 
> > Still, I'd like to have an except clause in a permission
> statment as
> > well, which can be used for a differenct purpose, i.e., giving
> > different permissions to some groups of the watchers.
>
> I'm sorry to sound like a broken record: People requesting features
> that break overall processing models should please have the kindness
> to provide motivation beyond "it could be useful".

As I didn't want to mix issues; WHY, WHAT and HOW,
I sent out a separate note on this with a CUG example,
which might not be convincing enough.
Although I carelessly used the term 'black list' to simplify
the explanation, it could be about any exception to a permission
statement.

> > In the case of Option #1, the rule enforcer should drop all the
> > permission statements in the rule set in order to prevent those
> > should-be-excepted watchers from accidentally obtaining
> information,
> > if there is an exception statement which cannot be
> understood. i.e.,
> > no permission is granted to anybody at all. In the case of
> Option #2,
> > the rule enforcer should drop the permission statements
> with unknown
> > except clauses, which still allows some watchers to obtain
> > information. It seems to me that both options give us the ways to
> > ensure the privacy-safe even if the rule enforcer does not
> support the
> > except mechanism, and rather the latter is more elastic or
> > fault-tolerant. Or is this just plausible?
>
> Please review the discussion on why this doesn't work when rules are
> composed from multiple sources.

Sorry about my lame explanations.

The issues I tried to raise here are of the influence of
introducing Capability A which is not supported by its rule enforcer X
and of the forward compatibility as well.

This will not be a problem if the rule enforcer supports an exception
capability,
but I was caught by the statement:
 "GEOPRIV might then decide not to support the exception list type, but
   the regular list type would be compatible."

It will make all the permission statements useless to introduce
a separate exception list which is not supported by its rule enforcer
unless the privacy-safe policy is broken, which should be rather a
problem.
If it exists in a rule set, not only a separate exception list
but an entire rule set needs to be dropped. Otherwise those listed
people
will never be excluded once they are granted by other permission
statements.

Then, suppose this exception list is one of the extenstion to the core
xcap-auth and belongs to a different namespace.
If this exception clause is separated from the normal permission,
the rule enforcers without its support should
 - ignore the entire rule set,
   * which requires the knowledge about this particular extension, or
   * disallowing any extension at all, which is not forward compatible,
OR
 - ignore the unknown elements,
   * which will violate the privacy, as the remaining

If exception clauses are attached to permission statements, on the other
hand,
the privacy-safe mechanism mentioned in section 4.4 of geopriv-policy
will work
and some of the rule set will survive, as only the permission statements
with unknown
exception elements can be dropped.

I believe the except clause in a permission statement is rather
privacy-safe without
giving up the entire rule set, while I think a separate extension list
is more readable
in some cases.
 
Regards,
-----
Naoko ITO / NEC

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon Nov 10 10:16:26 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST