Subject: [Simple] Presence auth rules: authenticated condition and exceptions

From: [email-masked]
Date: Wed, 10 Nov 2004 14:33:45 +0200

Hi,

I know this has been discussed several times, but I'd still like to propose it once again.

I believe the conclusion of yesterday's SIMPLE meeting was that there will be a new condition for pres auth rules called authenticated, which would be fulfilled by any request that came from an authenticated source. I would like to include the exception clause for that, which would allow "blacklisting" _within_ the scope of authenticated identities. Currently this is only allowed within a single domain. While such blacklisting would be pretty useless in systems where it is easy to generate new authenticated identities, it would be valuable in more restricted systems where there is certain cost/policy for obtaining identities. I understand that once more and more domains are interconnected to the system, the easiness of getting a new identity is based on the "weakest link", and thus it is hard to maintain the restrictiveness for large multi-domain systems. Nevertheless, there is strong user expectation for this type of feature. 

Thanks,
	Markus

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 12 Nov 2004 22:34:26 -0500

Due to the basic premise of additive permissions, it is unlikely that 
blacklisting is going to work as users expect. Rules can only add 
permissions, they cannot take them away. This means that if there is any 
more generic rule that, for example, allows authenticated (but unknown) 
users to request permission to subscribe, the blacklist would also have 
to be included in that rule. This seems rather brittle and likely to 
cause surprises, but is possible.

To address the other issue raised in the SIMPLE WG session discussion 
earlier this week: One possible proposal, instead of an authenticated 
flag, is to allow a wildcard character in the <id> element, as in

<id>*</id>

which matches any *authenticated* identity (whether the rules have 
access to the name or not). This would allow to express the desired 
behavior of querying for subscription permission. Non-authenticated 
names would not match such <id>-tagged rules, but could be matched by 
leaving out the <identity> match altogether, as before. I believe this 
also allows us to get rid of the not-very-well-defined case of anonymous.

We could add a 'do not match these' clause to rules, i.e., a condition 
on identity that causes the rule *not* to match. A fictitious example 
that extends the existing domain-level match (<domain> + <except>):

<identity>
   <id>*</id>
   <except>[email-masked]</except>
   <except>[email-masked]</except>
</identity>

The disadvantage is that this does add more failure cases, albeit 
harmless ones, such as

<identity>
   <id>[email-masked]</id>
   <except>[email-masked]</except>
</identity>

Here, the <except> is meaningless since it would never match to begin with.

As I mentioned above, this only allows true blacklisting if the <except> 
is included in all "*" rules.

Henning

[email-masked] wrote:
> I believe the conclusion of yesterday's SIMPLE meeting was that there
> will be a new condition for pres auth rules called authenticated,
> which would be fulfilled by any request that came from an
> authenticated source. I would like to include the exception clause
> for that, which would allow "blacklisting" _within_ the scope of
> authenticated identities. Currently this is only allowed within a
> single domain. While such blacklisting would be pretty useless in
> systems where it is easy to generate new authenticated identities, it
> would be valuable in more restricted systems where there is certain
> cost/policy for obtaining identities. I understand that once more and
> more domains are interconnected to the system, the easiness of
> getting a new identity is based on the "weakest link", and thus it is
> hard to maintain the restrictiveness for large multi-domain systems.
> Nevertheless, there is strong user expectation for this type of
> feature.
> 
> Thanks, Markus
> 
> _______________________________________________ Simple mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/simple