Subject: [Geopriv] presence authorization issue: anonymous, authenticated, etc.

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 04:23:28 -0500

Folks,

We've had a few stalled discussions and stalled threads (most recently
on the geopriv list) on the issue of what the common policy and/or
presence authorization specications should provide in terms of
conditions that match any authenticated identity, and whether or not an
unauthenticated identity counts as anonymous or not.

For background material, check out the meeting minutes from the last
SIMPLE session:

http://www.softarmor.com/simple/meets/ietf61/proceedings/simple61-session1-minutes.html

and a recent thread on geopriv:

http://www.ietf.org/mail-archive/web/geopriv/current/msg00519.html

We need to resolve this issue. It is a gating factor for common policy 
and the presence authorization work.

Dean put up a slide during the SIMPLE session last time which attempted 
to figure out whether the concepts of anonymous and unauthenticated were 
really separable. Some further thoughts on when such combinations can occur:

Unauthenticated, Anonymous: this would happen when the From field is 
present with the value of anonymous and there is no P-A-ID or Identity 
header field.

Unauthenticated, Not Anonymous: From field is present, but with a value 
that is not anonymous

Authenticated, Anonymous: There is a P-A-ID which a value like 
sip:[email-masked], or a From field that is 
sip:[email-masked] and an Identity field signed by provider.com. 
Seems reasonable.

Authenticated, not anonymous: the normal case

I think its fair to say that if a request is NOT authenticated, there is 
really no difference between anonymous and not anonymous from a policy 
perspective; in either case the originating identity is as good as 
useless. Thus, we'd like to be able to specify policies for three cases: 
unauthenticated, authenticated and anonymous, and authenticated and not 
anonymous.

However, it is also reasonable to say that one would provide different 
access to presence for anonymous and authenticated users than 
unauthenticated users. Indeed, the permissions one would apply for 
unauthenticated users really represent the 'baseline' permissions - no 
one would ever receive fewer permissions than those guys. Indeed, the 
question is whether unauthenticated users would ever get any permissions 
beyond the minimum.

I would propose that the answer is no, and then make the following 
concrete proposal:

1. An unauthenticated request never matches any rules, and thus never 
has any permissions granted

2. A rule with no conditions matches any authenticated request. Thus, to 
specify permissions that go to any authenticated request, you would have 
rules with no conditions.

3. A rule with some conditions matches if those rules match and the 
request is authenticated. This means that the <anonymous> permission 
assumes the request is authenticated.

I believe this proposal meets the requirements outlined by Aki; that is, 
to be able to define a baseline permission of "confirm" for any 
authenticated user, and then for users that get granted, provide a 
permission of "allow". It also allows for expression of policies 
separately for the three main cases above.

This proposal would require the following changes:

1. the geopriv common policy needs to be explicit on the meaning of a 
rule with no conditions, that it means it applies to any authenticated 
request

2. the presence auth rules needs to update the definition of the 
<anonymous> condition

Can we agree on this and move forward?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 08:44:47 -0500

> has any permissions granted

If I follow you, this means that an unauthenticated user gets no 
presence information at all. That seems too strong. I may well be 
willing to provide *some* information to *anybody*, and shouldn't be 
prevented from specifying such a policy.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 09:44:32 -0500

> sip:[email-masked] and an Identity field signed by provider.com. 

A different way of saying the same thing is that this is domain-level 
authentication. I don't think it matters if it says [email-masked] or 
[email-masked], but only example.com can be authenticated (e.g., 
via TLS certs). The important part about this "anonymous" authentication 
is that the authenticating domain may have some way to hold the party 
responsible, even if the PA doesn't know who it is and has no direct 
relationship with that party.

> Authenticated, not anonymous: the normal case

Authenticated (in general) would presumably also include other 
mechanisms, such as a Digest-authenticated SUBSCRIBE or maybe even TLS.

> question is whether unauthenticated users would ever get any permissions 

I agree with Paul that unauthenticated users may on occasion get access 
to data and that we would want to be able to specify this access. Think 
of a bus tracking application or other public data. Another contrived 
example: anonymous/unauthenticated users can subscribe to get flight 
tracker information to within a few miles (insufficient for 
missile-aiming), but certain authenticated users (e.g., the FAA) get 
precise location.

> has any permissions granted

Disagree, as per above.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 10:28:03 -0500

Henning Schulzrinne wrote:

>> I think its fair to say that if a request is NOT authenticated, there 
>> is really no difference between anonymous and not anonymous from a 
>> policy perspective; in either case the originating identity is as good 
>> as useless. Thus, we'd like to be able to specify policies for three 
>> cases: unauthenticated, authenticated and anonymous, and authenticated 
>> and not anonymous.
>>
>> question is whether unauthenticated users would ever get any 
>> permissions beyond the minimum.
> 

I was thinking of much more mundane cases. For instance any address that 
corresponds to a public information source - for instance the Chamber of 
Commerce, or just an enterprise. I hope I will be able to check the 
presence status of sip:[email-masked], and at 
least find out if they are open or closed. They have no reason to be 
secretive, so may well expose even more info to everybody - even 
anonymous watchers.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 15:25:07 -0500

OK, looks like my original proposal is not going to cut it.

Let me make the following alternative proposal that allows users to set 
policies for unauthenticated users:

1. a rule with no condiitons matches any subscription, authenticated or 
not, anonymous or not

2. a rule with an <identity> element assumes that the identity listed is 
authenticated; unauthenticated identities don't match those conditions.

3. a rule with an <anonymous> element assumes that the anonymous request 
is authenticated; unauthenticated identities don't match the <anonymous> 
condition.

4. we define an <any-identity> condition that matches any authenticated 
identity. It becomes a valid child of <identity>. This is similar to 
hennings proposal of using a wildcard in the value of <id>. However, I 
prefer doing this, so that we can keep the grammar of <id> defined to 
always be a URI, rather than allowing either a URI or *. i.e., the two 
approaches are identical semantically but I prefer this more explicit 
syntax.

The definition of "authenticated" can be based on provider policies 
about what authentication strengths suffice. We won't try to allow users 
to control that.

The document changes needed to support this are:

1. common policy defines the meaning of a rule with no conditions, as 
matching any request

2. common policy makes it clear that the <id> element matches only for 
authenticated identities with that value

3. common policy defines an additional value for <identity> called 
<any-identitiy> per above

4. presence policy updates the definition of anonymous to reflect that 
it means authenticated

5. presence policy has a discussion on how the <any-identity> is not 
useful for black lists, but rather for setting "baseline" policies that 
get applied to a broad set of users representing a minimum level of 
permissions.

If you but the argument in item 5 above, it is not needed to add an 
<except> kind of clause for <any-identity>, I believe. That is, any kind 
of permission that applies for any authenticated user should also apply 
to any user in particular. That is, if I set my permissions for 
<any-identity> to put subscriptins in the pending state, then every 
other authenticated user ought to have a permission which is at least 
that permissive.

This means that I couldn't specify that any authenticated user gets put 
in pending, but bob gets blocked.

Is this more workable?

I'd love to close on this before the -00 deadline so it can be reflected 
in the respective docs.

Thanks,
-Jonathan R.

Paul Kyzivat wrote:

>>> policy perspective; in either case the originating identity is as 
>>> good as useless. Thus, we'd like to be able to specify policies for 
>>> three cases: unauthenticated, authenticated and anonymous, and 
>>> authenticated and not anonymous.
>>>
>>> However, it is also reasonable to say that one would provide 
>>> different access to presence for anonymous and authenticated users 
>>> than unauthenticated users. Indeed, the permissions one would apply 
>>> for unauthenticated users really represent the 'baseline' permissions 
>>> - no one would ever receive fewer permissions than those guys. 
>>> Indeed, the question is whether unauthenticated users would ever get 
>>> any permissions beyond the minimum.
>>
>>
>> I agree with Paul that unauthenticated users may on occasion get 
>> access to data and that we would want to be able to specify this 
>> access. Think of a bus tracking application or other public data. 
>> Another contrived example: anonymous/unauthenticated users can 
>> subscribe to get flight tracker information to within a few miles 
>> (insufficient for missile-aiming), but certain authenticated users 
>> (e.g., the FAA) get precise location.
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 16:39:37 -0500

inline.

Henning Schulzrinne wrote:

>> Unauthenticated, Not Anonymous: From field is present, but with a 
>> value that is not anonymous
>>
>> sip:[email-masked] and an Identity field signed by 
>> provider.com. Seems reasonable.
> 
> 
> authentication.

Well, for the Identity case, yes, since its fundamentally built on a 
domain authentication model. P-A-ID, since you are not validating the 
assertions, allows you to assert domain-less identities, like 
sip:[email-masked] which is a non-existent domain by 
definition.

  I don't think it matters if it says [email-masked] or
> via TLS certs).

We aren't normally authenticating the identity of the message originator 
by TLS certs. We have P-A-ID, which uses inter-domain TLS but not to 
verify the identity or domain of the sender, but rather to validate the 
identity of the peer provider. For draft-ietf-sip-identity, there is no 
TLS, the From field is verified by using the domain cert obtained from 
the reference in the Identity header.

  The important part about this "anonymous" authentication
> relationship with that party.

Thats true assuming it had records of who the caller was, yes.

> mechanisms, such as a Digest-authenticated SUBSCRIBE or maybe even TLS.

Yes.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 16:56:51 -0500

> the reference in the Identity header.

I agree that there may be multiple layers in-between, but the basic 
premise is that

- some domain knows an individual at some level, but hides the "real" 
identity

- it then contacts the PA, who believes the peer domain identity

A truly anonymous identity, i.e., where some random IP address sends a 
self-signed cert, doesn't strike me as any different from the 
unauthenticated case.

> Thats true assuming it had records of who the caller was, yes.

If not, I don't see the practical difference to unauthenticated. If I 
can't hold the party responsible, it doesn't matter if it authenticated 
or not. It is not even clear that I know what such 
authentication-without-identity (at the origin) would mean.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2005 18:34:00 -0500

> is authenticated; unauthenticated identities don't match the <anonymous> 

Functionally these three are fine. I'm inclined to quibble about the 
precise terminology used, because I think this is less than intuitive. 
Would be clearer if it was <authenticated-anonymous> or something like 
that. But I'm not going to argue as long as the meaning is well documented.

> approaches are identical semantically but I prefer this more explicit 

Does <any-identity> match the things that <anonymous> matches?

I hope not.

> about what authentication strengths suffice. We won't try to allow users 

Sounds good.

> 1. common policy defines the meaning of a rule with no conditions, as 

While I have no problem with using rule with no conditions for this 
purpose, if it is easier, it would also be ok to provide a special rule 
(e.g. <all>) for this.

> in pending, but bob gets blocked.

I'm not sure about that one. I know logically if somebody can get a 
result by using some random phone then it makes no sense to give them 
less if they call from their own phone. But I am also pretty sure that 
complaints about it will come up constantly and we will be cursed until 
we "fix" it. So I think we need a way to say this.

I know this is pretty unreasonable. So please convince me that we won't 
be hounded to death if we don't provide it.

> Is this more workable?

Otherwise yes.

	Paul

>>>> I think its fair to say that if a request is NOT authenticated, 
>>>> there is really no difference between anonymous and not anonymous 
>>>> from a policy perspective; in either case the originating identity 
>>>> is as good as useless. Thus, we'd like to be able to specify 
>>>> policies for three cases: unauthenticated, authenticated and 
>>>> anonymous, and authenticated and not anonymous.
>>>>
>>>> for unauthenticated users really represent the 'baseline' 
>>>> permissions - no one would ever receive fewer permissions than those 
>>>> guys. Indeed, the question is whether unauthenticated users would 
>>>> ever get any permissions beyond the minimum.
>>>
>>>
>>>
>> I was thinking of much more mundane cases. For instance any address 
>> that corresponds to a public information source - for instance the 
>> Chamber of Commerce, or just an enterprise. I hope I will be able to 
>> check the presence status of 
>> sip:[email-masked], and at least find out if 
>> they are open or closed. They have no reason to be secretive, so may 
>> well expose even more info to everybody - even anonymous watchers.
>>
>>     Paul
>>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 22:14:30 -0500

> 1. a rule with no condiitons matches any subscription, authenticated or 

I think this has to be true. I don't see what else could work according 
to the basic design.

> authenticated; unauthenticated identities don't match those conditions.

Agreed. The text should probably at least provide examples of what 
'authenticated' means.

> is authenticated; unauthenticated identities don't match the <anonymous> 

Does the rule engine have to know which URL instances are actually 
anonymous? This increases the assumption on the type of matching needed.

Do we really need 'any anonymous user', as opposed to 'anonymous users 
from a particular domain'?

> approaches are identical semantically but I prefer this more explicit 

Can you give an example how this would be used? Is this to address the 
'anybody within a domain' case or something else?

---

From: Aki Niemi <[email-masked]>
Date: Tue, 22 Feb 2005 11:56:36 +0200

ext Jonathan Rosenberg wrote:
---snip---

> in pending, but bob gets blocked.

Almost. Except that I don't believe we can make a constraint as above 
and not allow the <except> in <any-identity>. The whole point in 
reactive authorization is to be able to block Bob for good, instead of 
getting that "Bob is pending authorization from you" message forever and 
ever. Or can you explain why that pop-up for reactive authorization 
should only have an "Allow" button, instead of both an "Allow" and "Block"?

So I still believe that the solution presented in my original post, or 
in Henning's post is the way to go. (The difference was really only in 
whether to have an <id>*</id> or an <any /> construct for indicating the 
"any authenticated identity" condition.)

Cheers,
AKi

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Feb 2005 22:14:50 -0500

I wonder if a better solution wouldn't be a completely separate 
black-listing and identity filtering mechanism that is (logically) 
placed ahead of the privilege system. In reality, do blacklists need 
more shades of gray than "go away, you're not welcome here"? (This would 
likely be part of some general form of spam filtering.)

Jonathan Rosenberg wrote:
> Aki,
> 
> Indeed, we are back to the main point of dispute I suppose we have 
> always had on this topic.
> 
> The problem is that, as you know, the model of common-policy is based on 
> additive permissions. You are not supposed to be able to take away a 
> permission, only grant one. What you are asking for is basically to 
> grant everyone a permission for "pending", but then to be able to take 
> it away for bad users. The scope of "everyone" - any authenticated 
> identity - is sufficiently large, that given the ease with which 
> identities can be minted in certain domains, this will basically prove 
> ineffective.
> 
> That said, I don't dispute that people are used to the model of "putting 
> someone on a blacklist", and without this, a basic version of that won't 
> be possible.
> 
> So, the dilemma - do we provide a gun with which we allow users to shoot 
> themselves in the head, because they are asking for it?
> 
> I've been adamantly against it, but am a bit torn since I do realize it 
> is a desired feature from a business perspective. I welcome other 
> opinions on this topic, perhaps from folks we havent heard from before....
> 
> Thanks,
> Jonathan R.
> 
> Aki Niemi wrote:
> 
>>
>>
>>> useful for black lists, but rather for setting "baseline" policies 
>>> that get applied to a broad set of users representing a minimum level 
>>> of permissions.
>>>
>>>
>>>
>>> <except> kind of clause for <any-identity>, I believe. That is, any 
>>> kind of permission that applies for any authenticated user should 
>>> also apply to any user in particular. That is, if I set my 
>>> permissions for <any-identity> to put subscriptins in the pending 
>>> state, then every other authenticated user ought to have a permission 
>>> which is at least that permissive.
>>>
>>> This means that I couldn't specify that any authenticated user gets 
>>> put in pending, but bob gets blocked.
>>>
>>>
>>> Is this more workable?
>>
>>
>>
>> getting that "Bob is pending authorization from you" message forever 
>> and ever. Or can you explain why that pop-up for reactive 
>> authorization should only have an "Allow" button, instead of both an 
>> "Allow" and "Block"?
>>
>> whether to have an <id>*</id> or an <any /> construct for indicating 
>> the "any authenticated identity" condition.)
>>
>> Cheers,
>> AKi
>>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Feb 2005 22:02:31 -0500

Aki,

Thanks,
Jonathan R.

Aki Niemi wrote:

>> kind of permission that applies for any authenticated user should also 
>> apply to any user in particular. That is, if I set my permissions for

---

From: Aki Niemi <[email-masked]>
Date: Wed, 23 Feb 2005 10:13:36 +0200

> identities can be minted in certain domains, this will basically prove 

I think this argument deserves some further analysis. I attempted that a 
while back in a post:

http://www1.ietf.org/mail-archive/web/geopriv/current/msg00381.html

In essence, what you are saying above is that because identities can be 
minted easily in domain B, it automatically leads to valid credentials 
being generated for (my) domain A for that identity. If this was true 
given a *real* authentication mechanism in place (and not one based on a 
weak notion of transitive trust, for example), then what purpose does 
authentication serve in this system anyway?

I don't think authorization and authentication can be lumped together 
here in this way. Even if domain B has a nonchalant way of giving out 
identities, it is still domain A's business to determine who's got valid 
credentials in its domain. As an example, domain A could require a 
digest username/password, and the assignment of those credentials is 
solely the responsibility of domain A, and can be as scrutinizing as 
required.

So apologies for sounding like a broken record, but I think ultimately 
in such a system that can't safely handle a block-list, authentication 
is broken, not authorization.

> opinions on this topic, perhaps from folks we havent heard from before....

I hope to see this as well, especially since this seems to be a 
potential "make-or-brake" issue where the implications can be quite big 
depending on which direction we take.

Cheers,
Aki

---

From: Hans Persson <[email-masked]>
Date: Mon, 21 Feb 2005 09:22:16 +0100

> the reference in the Identity header.

I'm probably taking a risk by writing this first thing on Monday morning
*yawn* but as far as I can see there may well be a TLS cert involved in
draft-ietf-sip-identity:

draft-ietf-sip-identity-04.txt:
>   The Identity-Info header MUST contain either an HTTPS URI or a SIPS
>   URI.  If it contains an HTTPS URI, the URI must dereference to a
>   resource that contains a single MIME body containing the certificate
>   of the authentication service.  If it is a SIPS URI, then the
>   authentication service intends for a user agent that wishes to fetch
>   the certificate to form a TLS connection to that URI, acquire the
>   certificate during normal TLS negotiation, and close the connection.

(I assume you really meant Identity-Info, not Identity)

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Feb 2005 11:21:03 -0500

> authentication serve in this system anyway?

I think you're missing the central problem and the core difference 
between white lists (additive permissions) and black lists. Assuming 
strong authentication is necessary and sufficient for white lists, but 
has little bearing on blacklists.

Example: Yahoo performs (reasonably) strong authentication and 
authorization on its users, so that only the owner of the account can 
get access to the service. However, it is trivial for the same (bad) 
person to get another account that is equally strongly authenticated, 
with a different identifier, but easily bypasses the earlier blacklist 
entry.

Another example: Our local email system strongly authenticates users 
when submitting email. However, I can easily submit messages using
hgs@cs
henning@cs
schulzrinne@cs
h.schulzrinne@cs
hgs+foo@cs
hgs+bar@cs
(and any other variation of hgs+?@cs) as the 'From' address. I can make 
up these '+' identifiers on the fly. Again, the authentication model is 
quite sufficient for a whitelist (nobody else can create hgs+?@cs 
messages), but useless for a blacklist.

As we have elaborated on in a techreport (details available on request), 
it is insufficient to know the authentication strength for identity 
assertion algorithms. In addition, one needs to carefully consider the 
ease of identifier creation and whether individuals can have one, many 
or an infinite supply of identifiers. Unless you restrict the domain of 
applicability to those with "single user, single identifier" policies 
that you trust, this is all mostly make-believe security.

> is broken, not authorization.

I think you're fundamentally mis-understanding the relationship of 
authentication to identifier uniqueness and predictability. Until we 
arrive at a common understanding, we'll keep talking past each other.

Given the very different properties of whitelists and blacklists, I had 
suggested that we create a separate mechanism for the latter, with 
appropriate buyer-beware warnings. That way, we don't have to weaken the 
additive properties of the main policy mechanism.

Henning

---

From: Aki Niemi <[email-masked]>
Date: Fri, 25 Feb 2005 13:36:13 +0200

Inline.

ext Henning Schulzrinne wrote:
>> In essence, what you are saying above is that because identities can 
>> be minted easily in domain B, it automatically leads to valid 
>> credentials being generated for (my) domain A for that identity. If 
>> this was true given a *real* authentication mechanism in place (and 
>> not one based on a weak notion of transitive trust, for example), then 
>> what purpose does authentication serve in this system anyway?
> 
> 

Strongly authenticated at yahoo.com or cs.columbia.edu, not necessarily 
at jippii.fi or nokia.com. But granted, in most practical scenarios, 
this would mean exceptions in the <any> condition would experience 
inflation quite quickly.

> that you trust, this is all mostly make-believe security.

I do get the point you make above, so the question is: could we make the 
any-except construct little less susceptable to identity minting by 
taking in this notion of weak domains?

Would it help if we define the <any> identity condition in such a way 
that the exceptions can also be to domains?

<conditions>
    <identity>
       <any-authenticated>
          <except>
             <domain>example.net</domain>
             <id>[email-masked]</id>
          </except>
       </any-authenticated>
    </identity>
</conditions>

Then, for example upon witnessing a lot of harrassing requests for
authorization from a specific domain the rule maker could add that
domain as an exception to the "any" rule that grants the "confirm"
permission.

>> identities, it is still domain A's business to determine who's got 
>> valid credentials in its domain. As an example, domain A could require 
>> a digest username/password, and the assignment of those credentials is 

I actually think I understand the argument better now, thanks. Does the 
proposal address the disagreement? I think if we are fine with allowing 
per-domain blacklists, then this is the missing component that links 
those blacklists with the global wildcard structure in a clean, 
privacy-safe way.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Feb 2005 08:36:40 -0500

> this would mean exceptions in the <any> condition would experience 

The problem is also that for most practical cases, you don't know the 
policy of the remote domain. (I'm assuming that if there's a really 
annoying person within your own company that you'd like to blacklist, 
that there are other local mechanisms to deal with them.)

Since the bad actor can trivially create a new identity for each new 
SUBSCRIBE, the blacklist will be completely ineffective.

Early spam filters had blacklists; we now know that they are useless 
(and would be largely useless even with SPF).

> taking in this notion of weak domains?

Under the current circumstances, I don't see how you can reliably 
determine this. I have no clue what Nokia's domain policy is and no 
automated way of finding out.

> that the exceptions can also be to domains?

Yes, I thought we discussed this earlier (at the last meeting?), but 
maybe this got lost somewhere.

---

From: Aki Niemi <[email-masked]>
Date: Fri, 25 Feb 2005 16:19:50 +0200

Inline.

ext Henning Schulzrinne wrote:
>> I do get the point you make above, so the question is: could we make 
>> the any-except construct little less susceptable to identity minting 
>> by taking in this notion of weak domains?
> 
> 

Exactly, but this is a limitation already inherent in the common policy 
domain wildcard conditions. I think in the general case determining this 
and being able to discriminate against "weak" domains will be hard for 
the average-joe.

But then again maybe not that hard, since I think people already today 
have a pretty good idea about these policies in email accounts. Everyone 
knows that a username in gmail.com is in relative short supply compared 
to some other free email providers. Corporate email accounts usually 
have much tighter policies.

> maybe this got lost somewhere.

Apologies if I missed this before. It is sort of obvious, must admit.

There is one catch to this, however. I think such a condition should 
only ever be applied to something like a "confirm" permission. It would 
not work well with an "allow", quite naturally. That would be shooting 
oneself in the leg, like Jonathan was worried would happen. But this 
should be relatively easy to capture in specification writing.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Feb 2005 13:13:05 -0500

> and being able to discriminate against "weak" domains will be hard for 

Agreed; this also seems much better handled in a general spam control 
policy, which can take multiple factors, such as domain policies, into 
account. I suspect that in many such cases, these policies, like today 
for email, will be on an organization-wide basis, rather than individual 
policy rules.

> have much tighter policies.

But see my example: We have very tight policies on handing on UNI 
(university network IDs), but still an infinite supply of personal 
email-style identifiers. I doubt that the outside world knows this (or 
cares).

> should be relatively easy to capture in specification writing.

I'm not so sure. If things are defined as follows:

- No rule => denied subscription; no access to any data

- Bad apples list => polite block or deny

- No positive identity ("anybody except"), with exceptions => the world 
except the bad domains/names get the base level access and maybe 
'confirm', with the caveat that name-level exceptions are likely to be a 
very crude and "leaky" privacy screen

A related question that we have never addressed is the following use case:

"Random strangers can subscribe to my basic, public presence information 
without confirmation, but I need to confirm subscriptions to more 
detailed information"

I think the best solution is to declare two different presentity names 
for that.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2005 10:05:45 -0500

Henning Schulzrinne wrote:
> 
> 
> Aki Niemi wrote:
> 
>> Exactly, but this is a limitation already inherent in the common 
>> policy domain wildcard conditions. I think in the general case 
>> determining this and being able to discriminate against "weak" domains 
>> will be hard for the average-joe.
> 

It seems to me that there are a whole range of cases here. Lumping them 
all into the general category of SPAM is useful in some cases, but isn't 
helpful all the time.

General mechanisms, managed by the organization, may be helpful for 
dealing with malicious spammers. But they aren't so helpful for dealing 
with "pests". Yet pests can be a significant problem.

>> have a pretty good idea about these policies in email accounts. 
>> Everyone knows that a username in gmail.com is in relative short 
>> supply compared to some other free email providers. Corporate email 
>> accounts usually have much tighter policies.
> 
> 

People can be very resourceful. It won't take long for somebody to begin 
to discern the pattern of addresses you use. (e.g. [email-masked])

I think there will continue to be a demand for flexible techniques to 
denote specific classes of addresses based on patterns in the address.

>> only ever be applied to something like a "confirm" permission. It 
>> would not work well with an "allow", quite naturally. That would be 
>> shooting oneself in the leg, like Jonathan was worried would happen. 
>> But this should be relatively easy to capture in specification writing.
>>
> 

Yes. Its the bad apples list where you want a lot of flexibility in 
description. Note that I may not have to fully understand the domain 
name assignment policy to describe a matching algorithm sufficient for 
my needs. I may decide to simply exclude [email-masked]. This may 
overreach and exclude some I didn't intend to exclude, but that may 
still be ok, because I will never have need to correspond with them anyway.

> I think the best solution is to declare two different presentity names 

I agree it is a problem that we haven't dealt with. But I am not sure 
that two distinct presentity names is the right solution. Then I need to 
manange two names, and ensure that the right name gets in the hands of 
each person.

It is also a problem when using phone numbers as identities. We've been 
struggling with how to use presence as an enabler for telephony when 
phone numbers are in use, and it is a problem because of this.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Feb 2005 14:17:37 -0500

> denote specific classes of addresses based on patterns in the address.

Agreed, but we need to find a reasonable cut-off point of complexity and 
predictability. You seem to be arguing for supporting general regular 
expressions or at least "glob" style expressions, which is beyond what 
we're currently describing, for either black or whitelists.

> still be ok, because I will never have need to correspond with them anyway.

If they are polite blocked, I wouldn't know that these inviduals existed 
at all, even though I might want them to be able to "knock" (SUBCRIBE + 
confirm).

> manange two names, and ensure that the right name gets in the hands of 

Unlike with unlisted phone numbers, getting the wrong one to a 
subscriber isn't as bad since the name doesn't convey authorization. I 
do agree that this name mapping is sub-optimal since it makes it fairly 
obvious that you're handing out different rights and makes it really 
difficult to change rights (upgrade or downgrade) without handing out a 
new name.

You'd almost want some kind of caller preferences where the SUBSCRIBEr 
can say "I'd like to ask for confirmation" or "I'm not willing to 
authenticate so just give me what you are going to give to random 
strangers" or "I want the maximum possible information and am willing to 
jump through a ChoicePoint verification and lie detector test if I have 
to". (Might be easier to just pick up a suitable identity from your 
friendly identity retailer courtesy of that same company, but we'll 
leave that aside.)

> phone numbers are in use, and it is a problem because of this.

I don't quite see the connection. Are you saying that I want to 
subscribe to your presence, where you're identified by your phone 
number? ENUM would seem to solve that problem.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2005 19:38:21 -0500

Henning Schulzrinne wrote:
>> People can be very resourceful. It won't take long for somebody to 
>> begin to discern the pattern of addresses you use. (e.g. 
>> [email-masked])
>>

Yes, I think that something of that sort may be needed, or at least 
desirable. (glob style anyway.)

Something else that hasn't been touched upon is watchers whose identity 
is a tel uri. I think we have to expect that there will be such. Its 
ugly, but I think there will be need for special matching on various 
parts of these.

>> my needs. I may decide to simply exclude [email-masked]. This 
>> may overreach and exclude some I didn't intend to exclude, but that 
>> may still be ok, because I will never have need to correspond with 
>> them anyway.
> 

Sure. But if I have already rejected [email-masked], and then I 
reject hgs+foo, and hgs+bar, and a few more, I am going to want a way to 
reject hgs+* even if I have to take a risk that there aren't some valid 
hgs+xxxs.

>> that two distinct presentity names is the right solution. Then I need 
>> to manange two names, and ensure that the right name gets in the hands 
>> of each person.
> 

Yes, these are significant issues. Are you going to keep two different 
sets of business cards and make a decision about which one to give to 
someone? (The plain white ones, and the "platinum" ones.)

> friendly identity retailer courtesy of that same company, but we'll 

I haven't got a particular mechanism in mind. But I agree there is some 
similarity between saying "I calling but I just want your voicemail 
server", and saying "I want whatever presence I can get without going 
into pending and requesting approval".

>> It is also a problem when using phone numbers as identities. We've 
>> been struggling with how to use presence as an enabler for telephony 
>> when phone numbers are in use, and it is a problem because of this.
> 

The point was that phone numbers are somewhat scarce. You probably often 
won't be willing to have one for your buddies and another for everybody 
else. And then there will just be one on your business card.

And as I mentioned above, authorization of subscribers known by a number 
is also an issue.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Feb 2005 20:28:59 -0500

Paul Kyzivat wrote:

> desirable. (glob style anyway.)

So far, prefix (for user names) and postfix (for hosts) seems to be 
working for the examples (which is also similar to the SQL "LIKE %" 
facility).

> ugly, but I think there will be need for special matching on various 

I don't see tel:12*15*7

as all that useful.

> someone? (The plain white ones, and the "platinum" ones.)

I suspect this is more useful for the address you put on your web page 
("is my shop open?") vs. your business card.

> into pending and requesting approval".

I wonder if the caller preferences mechanism couldn't be extended to 
handle this type of mechanism pretty easily.