Subject: RE: [Simple] Comments on: First draft of text on semantic-based authorization policies [exceptions]

From: [email-masked]
Date: Tue, 23 Mar 2004 23:02:46 +0200

Henning,

I mean exceptions in the scope of whom a rule should apply to. Comments inline:

Henning Schulzrinne wrote:
> 
> I don't understand this comment. Black lists can easily be 
> implemented 
> by splitting them across domains. This is just a syntactic 
> transformation.
> 

As I understand it there is more to it. This is from the latest geopriv common policy draft:

---
   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
      Section 7.1 describing how exceptions can be made work.
---

So it is to my understanding impossible for instance to provide presence to everyone except an enumerated list of identities. This is usually what black-listing means.

> The note issue ('different information') is a more 
> interesting one. We 
> had earlier decided not to support lying, so this seems to 
> refer only to 
> free-form fields like 'note'. 

Well, lying can be done simply by publishing false information. I guess you mean that it wouldn't be allowed to provide user X with contradicting information compared to user Y (more accuracy seems to be fine). I think this is a feature that has some usefulness beyond just note.

> The problem you note can be 
> solved within 
> the framework by an ordering mechanism that associates a value with a 
> parameter. That way, the highest ("best") value would be picked, but 
> only one, instead of all. I think the easiest would be to 
> associate an 
> ordering with 'class' and just have the publisher upload different 
> tuples. I don't think it makes sense to use the policies to 
> set actual 
> presence values.
> 

I think this is a very good idea, and would solve this particular problem. There would just need to be a mechanism how to express the ordering within "class". "class" itself is going to need more specifying, since currently it is hard to use it among multiple PUAs.

> Exceptions greatly complicate the processing and, in conjunction with 
> external lists, are privacy-unsafe. Thus, I'm opposed to 
> including such 
> mechanisms. 

I suppose you mean now exceptions only, not the "class" ordering you just proposed yourself?

> Since people mean many different things when they 
> talk about 
> exceptions, it would be helpful if you could actually state 
> an exception 
> rule that you envision.
> 

Presentity has presence tuples A, B, C. (let's say B and C are otherwise the same, but have a different "note") 
He wants to enforce the following policy:
- Provide tuples A and B to everyone except Joe and Frank
- Provide tuples A and C to Frank (note, not B)
(Joe gets nothing)

Very simple, practical, and realistic - yet undoable with the current drafts.

> Henning

Markus

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 21:24:41 -0500

> 
> So it is to my understanding impossible for instance to provide
> presence to everyone except an enumerated list of identities. This is
> usually what black-listing means.

I'm finding it hard to believe that 'everyone in the world except A, B 
and C' is a useful service concept. My concern is that this promises 
privacy to users that may not understand the implications (and the 
uselessness of this). Can you imagine a system that allows any random 
user to obtain presence information?

I think the concept of 'everybody gets to ask for permission before 
subscribing except bad guys A, B and C who I've already told to get 
lost' is useful and might implementable by an appropriate ordering of 
actions. For example, if you order actions as

known_reject (highest), permit, ask, dont_bother (lowest, default)

the right thing happens. However, caveats about file merging apply.

> 
> I think this is a very good idea, and would solve this particular
> problem. There would just need to be a mechanism how to express the
> ordering within "class". "class" itself is going to need more
> specifying, since currently it is hard to use it among multiple PUAs.

There are two mechanisms I can think of:

- kludge: classes are ordered alphabetically

- mapping: classes are assigned ordinal numbers in the ruleset

> 
> 
> 
>> Exceptions greatly complicate the processing and, in conjunction
>> with external lists, are privacy-unsafe. Thus, I'm opposed to 
>> including such mechanisms.
> 
> 

Correct. The ordering follows the standard additive merging rules and is 
inclusion- and privacy-safe.

> Presentity has presence tuples A, B, C. (let's say B and C are
> otherwise the same, but have a different "note") He wants to enforce
> the following policy: - Provide tuples A and B to everyone except Joe
> and Frank - Provide tuples A and C to Frank (note, not B) (Joe gets
> nothing)
> 

I disagree - the 'everyone' service is a very dangerous one that will 
fool users into revealing information that they do not want. We 
shouldn't design systems that fail unsafe and invite trouble.

I suggested the action mechanism above since it provides a 'safety' - if 
it fails, you get to do an additional subscription approval, but at 
least you don't reveal your whereabouts or other sensitive information 
to the wrong people.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Mar 2004 21:24:41 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 02:59:36 -0500

There are a bunch of separable points in these various mails, so I'm
separating responses and changing the subject.

Henning Schulzrinne wrote:

>> presence to everyone except an enumerated list of identities. This
>> is usually what black-listing means.
> 
> 
> I'm finding it hard to believe that 'everyone in the world except A,
> B and C' is a useful service concept. My concern is that this
> promises privacy to users that may not understand the implications
> (and the uselessness of this). Can you imagine a system that allows
> any random user to obtain presence information?

I agree with Henning. What I really think you want, Markus, is to say
that, "for users within domains where I know that its hard to get new
identities easily, allow anyone except Joe and Bob". I believe thats
what you had in mind when you said:

> While in general this is the case, I don't think it should limit
> _all_ systems, some of which can deal with identities better than the
> Internet at large. Below is an example, beyond block-listing, how
> leaving out exceptions makes things difficult

With my definition above, the existing domain-based exceptions work 
fine. For example, if AOL wants to do black lists, they would do:

<rule>
<conditions>
<identity>
      <domain>aol.com</domain>
      <except>joe</except>
      <except>bob</except>
    </identity>
</conditions>

<actions>
   <accept-subscription/>
</actions>
</rule>

That is, you can use the existing mechanism to enumerate the domains in 
the trusted set which have this property. Today, we only really see 
single provider networks, where you can only subscribe to someone in the 
same domain. That is supported fine by the current mechanism. Of course, 
the standard caveats apply - you really need to understand the way the 
domain hands out identities before you set such a policy.

When we eventually run into networks where there are so many service 
providers amongst this "trusted set" that it becomes difficult to 
enumerate them, we might have a problem, but I think we can cross that 
bridge later.

> the right thing happens. However, caveats about file merging apply.

Henning - I dont understand how this is privacy safe. In your ordering, 
there is not a strictly increasing amount of information revealed as the 
values increase.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 02:59:36 -0500

<rule>
<conditions>
<identity>
      <domain>aol.com</domain>
      <except>joe</except>
      <except>bob</except>
    </identity>
</conditions>

<actions>
   <accept-subscription/>
</actions>
</rule>

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 03:15:40 -0500

[email-masked] wrote:
> [Presentity wants to give group "friends" a privileged access to his
> presence information. By default he gives out some information, but
> "friends" should receive a different view of the _same_ information.
> (Note that this is not additive, but we talk about different views,
> for instance showing a _different_ "note".) If exceptions are not
> allowed, "friends" will get the common information in addition to
> what should be given to them, making things confusing at the watcher
> side. (For instance a watcher get 2 tuples with the same Contact,
> having different notes.)] So I believe the main problem is that
> presence information is not always additive, but it can also be
> contradictive! Another huge problem is that there already exists many
> presence systems which have block-lists, and in some cases we would
> like to preserve the UI semantics even when the protocol stack is
> changed to SIP. Now it seems impossible. -> Proposal: Allow
> exceptions in SIMPLE, even though they are not there in the common
> policies.

to which Henning had suggested:
> The note issue ('different information') is a more interesting one.
> We had earlier decided not to support lying, so this seems to refer
> only to free-form fields like 'note'. The problem you note can be
> solved within the framework by an ordering mechanism that associates
> a value with a parameter. That way, the highest ("best") value would
> be picked, but only one, instead of all. I think the easiest would be
> to associate an ordering with 'class' and just have the publisher
> upload different tuples. I don't think it makes sense to use the
> policies to set actual presence values.

and to which Ted had commented:
> My take on this may be colored a bit by GeoPriv, but I don't think 
> this is a very useful change.  For a system that is fundamentally 
> about presence, a view that there is a set of real presence data 
> ("currently typing up a message to simple") that may be reflected in
> various ways ("busy" to a general watcher, "in my office" to my 
> colleagues, "interrupt okay" to my boss) seems to me pretty useful. 
> When I leave for lunch, all can be appropriately updated with 
> relation to the real data ("away" to a general watcher, "temporarily 
> out of office" to my colleagues, "available by cell" to my boss).
> 
> In a much more abstract system describing my characteristics, I could
> see a different view.  For a "favorite record" entry, for example, I
> could see saying "Stunt" to one set of people, "Rhythm of the Saints"
> to another, and "Carcassonne" to a third; these might reflect the
> kind of music I'd like to listen to with those people.  But these are
> relatively long lived entries, and unlikely to need updating on a
> many-times-a-day basis.  For entries which do,  updating each entry
> for each group each time would be painful.  The practical result of
> that is that you would have to define relationships among the groups'
> data sets, so that an update to an entry is reflected correctly in
> the others without having to define what the new value is in each
> set.  Doing that from a "base" set (a.k.a. the real data) seems like
> a useful model, since the application of the rules is cleaner than
> having set 5 depend on set 3 which depends on set 1 (which in the
> worst case depends on set 5 and runs you into real trouble).

I'm with Ted here. I think that the current model - where there is truly 
a "real" presence document, and policies merely define different levels 
of access to that data - is the right one. The problem Markus has 
raised, which is that I might want to have contradictory data sent to 
different watchers, is really a subset of a more general problem, which 
is that presence can contain contradictory information, even if I'm not 
lying. In systems where there are multiple sources of presence, it is 
entirely plausible for the data to be inconsistent. This can be because 
of timing and race conditions (source A found out about inavailability a 
few minutes before source B), because of differing interpretations of 
the same data by different sources, etc.

So, if you buy the argument that presence data can be inconsistent, the 
question is, who is best suited to sort out that inaccuracy. The class 
ordering mecahnism Henning proposes is based on the assumption that its 
the job of the presence agent to sort it out. However, I think that, in 
the general case, this goal is unachievable. We already have identified 
the note as one case where the PA can never sort out inconsistencies 
because they are interpretable only by people. There are many other 
cases too. What if my calendar app says I'm in the office today, but my 
cell phone reports I'm in a different state? How can the PA sort that 
out? It can't.

So, I would propose that it is a WATCHER problem to sort out any 
inconsistent data. The human has to interpret the data best they can, 
based on whatever context they have. For example, my boss might see my 
presence as "in the office and in a different state", and say to himself 
- "oh right, Jonathan took that last minute trip today, so he probably 
forgot to cancel that meeting, and he is likely out of state".

So, given that, I'm not sure I want to go down the path of specifying 
this well-defined ordering for data to sort out inconsistencies on the 
PA side.

"Lying" would be achieved by publishing inconsistent tuples, and then 
defining rules which give one set to one class of watchers, and the 
other set to a different class. If someone happens to get both, then its 
their job to sort it out.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Mar 2004 03:15:40 -0500

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2004 09:09:00 -0500

> there is not a strictly increasing amount of information revealed as the 

The idea is 'known reject' trumps all other values. Thus, if your 
identity matches such a rule, it gets bounced even if a more 
encompassing rule allows to request permission.

This is unnecessary if we agree that global blacklists are a bad idea 
even for the subscription (as opposed to information delivery) phase. My 
notion is only needed if you want to support the notion:

"Everybody in the world, in any domain, gets to *ask* to subscribe to my 
presence, but Alice, Bob and Carol have already been told to take a hike 
and thus shouldn't even be able to ask."

Is this the type of rule we want to be to support?

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 24 Mar 2004 09:09:00 -0500

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Mar 2004 09:18:15 -0800

At 9:09 AM -0500 03/24/2004, Henning Schulzrinne wrote:
>"Everybody in the world, in any domain, gets to *ask* to subscribe 
>to my presence, but Alice, Bob and Carol have already been told to 
>take a hike and thus shouldn't even be able to ask."
>

It's seems to me to be a lot easier just to keep telling them to take a hike
whenever they ask; is there a reason to optimize for this case that I'm
missing?
		regards,
				Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 24 Mar 2004 09:18:15 -0800

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2004 12:25:26 -0600

Ted Hardie wrote:
>> "Everybody in the world, in any domain, gets to *ask* to subscribe to 
>> my presence, but Alice, Bob and Carol have already been told to take a 
>> hike and thus shouldn't even be able to ask."
>>

The act of asking can become a kind of harrassment. Some time ago, I had 
a yahoo messenger user that continuously asked permission to watch my 
presence, but refused to identify themselves to me. This continued after 
I asked them to desist. Fortunately, yahoo messenger allowed me to block 
that ID, so I no longer get bothered by them.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Mar 2004 12:25:26 -0600

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 10:43:15 -0500

You can still achieve the functionality you want, Ben, without requiring 
the new rule Henning had proposed:

<rule>
<conditions>
   <identity>
     <domain>example.com</domain>
     <except>joe</except>
   <identity>
</conditions>

<actions>
   <ask-for-confirmation/>
</actions>
</rule>

<rule>
<conditions>
   <identity>
     <user>joe</user>
   <identity>
</conditions>

<actions>
   <deny-subscription/>
</actions>
</rule>

Of course, you need to be careful that the user joe is not a member of 
any other rule which grants a permission greater than 
"deny-subscription", but thats a fundamental property of the model in 
general.

-Jonathan R.

Ben Campbell wrote:

>>> my presence, but Alice, Bob and Carol have already been told to take 
>>> a hike and thus shouldn't even be able to ask."
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 10:39:35 -0500

inline.

Henning Schulzrinne wrote:

>> Henning - I dont understand how this is privacy safe. In your 
>> ordering, there is not a strictly increasing amount of information 
>> revealed as the values increase.
> 
> 

I understand that; its definitely a change in the model though, and 
could be confusing to users to have this special case where the behavior 
is different.

> and thus shouldn't even be able to ask."

The proposal doesnt solve the problem that made wildcards problematic to 
begin with, which was the ease of obtaining identities within certain 
domains. I can still be bothered by the same person who just keeps 
signing up for more yahoo accounts.

> Is this the type of rule we want to be to support?

I'm inclined to say no; I'd like to see if some kind of enumerated 
domain listing or something would address Markus' concern.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 10:43:15 -0500

<rule>
<conditions>
   <identity>

<actions>
   <ask-for-confirmation/>
</actions>
</rule>

<rule>
<conditions>
   <identity>
     <user>joe</user>
   <identity>
</conditions>

<actions>
   <deny-subscription/>
</actions>
</rule>

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Mar 2004 10:39:35 -0500

inline.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2004 17:43:18 -0500

> raised, which is that I might want to have contradictory data sent to 

I would not call this 'contradictory' data. For free-form data, I could 
easily have

sending to boss (from calendar): note = "Meeting with customer foo about 
new product introduction"

sending to colleagues: note = "Meeting with customer"

sending to friends, particularly those without RPIDS: note = "Please 
don't IM!"

These don't contradict each other at all.

> cell phone reports I'm in a different state? How can the PA sort that 

Again, this is not a contradiction. I can easily label three different 
tuples by class (or sphere), with different 'notes' in each. The PA then 
sends the right tuples to each recipient.

> inconsistent data. The human has to interpret the data best they can, 

This obviously does not work for the example I gave (and the one that 
I'm guessing Markus had in mind).

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2004 17:43:18 -0500