Subject: [SIMPLE] Authorization of resource list back-end subscriptions

From: "helei" <[email-masked]>
Date: Fri, 18 Jun 2004 11:32:08 +0200

The draft-ietf-simple-event-list-04 (expired, yes, but I hope it will be
revitalized soon) states that a resource list may have several subscribers.
It also states that the _RLS_ act as subscriber for the back-end
subscriptions to any non-local resources on the list.

This makes me wonder:
 - How can the non-local resources authorize the actual list subscribers
(those subscribing to the resource list)? The Watcher-info document would
only hold the RLS as a subscriber?
 - Why prohibit reuse of information from one back-end subscription when the
actual subscription is not associated with the list subscriber?

Shouldn't it be the _resource-list_ that acts as subscriber?

Best regards,
Henrik Leion

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2004 10:25:20 -0400

> only hold the RLS as a subscriber?

Ideally the RLS is prepared to act as the watcher's agent, including 
having credentials permitting it to authenticate as such.

> actual subscription is not associated with the list subscriber?

If the RLS has credentials to authenticate as agent for X when acting on 
  X's behalf, and as agent for Y when acting on Y's behalf, then data 
received via subscription on behalf of X should not be released to 
subscriber Y, because subscription on behalf of Y could have divulged 
different info.

OTOH, if the RLS always subscribes with a single set of credentials (its 
own), then there is probably no reason why it can't give that out to all 
its subscribers. (But in that case the RLS probably isn't going to 
receive the best information, because people won't trust who it is going 
to.)

	Paul

---

From: "Henrik Leion" <[email-masked]>
Date: Fri, 18 Jun 2004 17:07:13 +0200

[Inline comments after this suggestion]

I think the discussions on authorization rules, filters and watcher info
would allow a better and more powerful solution:

 - Why can't the resource-list acts as the subscriber to the non-local
resource, instead of the RLS. The watcher event template package would allow
the presentity to "roll-back" the two subscriptions to see who ultimately
will receive notifications from the list (by subscribing to
resource-list-uri.winfo, should this list contain any list, the presentity
could subscribe to them to).
 - The back-end resource should be allowed (if he can authenticate himself
to the RLS which is in another domain) to set authorization rules applicable
to him in the resource-list's authorization rule-set, in order to block his
information from reaching specific subscribers to the list.

Consequences:
 - The real users in the list will have the same control over their presence
information as in direct subscriptions, including filtering and
authorisation.
 - No need to upload credentials to server just to have lists with people
from other domains in them.
 - The RLS could reuse existing back-end subscriptions by checking
resource-list policy and updating resource-list watcher-info
 - OTOH, if the presentity has not created a complete authorization policy
and is not subscribing to the winfo of the list, new subscriptions might
starve.

/ Henrik Leion

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: den 18 juni 2004 16:25
> To: helei
> Cc: Simple mailinglist
> Subject: Re: [SIMPLE] Authorization of resource list back-end
> subscriptions
>
>
>
>
> helei wrote:

But what if we subscribe to a list, which contains an external list which
contains a user.
The second RLS would then only have the credentials for authorizing the
first RLS at best, not the subscriber. Right?

> receive the best information, because people won't trust who it is going

Isn't that a more likely scenario than people uploading credentials to
servers?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2004 16:43:59 -0400

Henrik Leion wrote:
> resource, instead of the RLS.

Well, that is an interesting thought. Possibly it could be made to work. 
A number of issues/implications (maybe not fatal) come to mind:

- what kind of credential could the RLS have and provide when 
subscribing that authenticates it as the resource-list?

- in case of private lists (e.g. I am the only one who subscribes to 
*my* buddy list) having credentials for my buddy list is no easier than 
having credentials for me.

- if the RLS server has lists L1 and L2 that both have a reference to 
presentity P, then it still can't use a single subscription to P and 
provide results to subscribers of both L1 and L2.

 > The watcher event template package would allow

Well, maybe it *could* but that sounds really cumbersome, expensive, and 
not especially reliable. Can I ever safely decide what to disclose based 
on who I think is currently subscribing to that list, rather than who 
potentially *could* subscribe to it?

> information from reaching specific subscribers to the list.

Huh? I don't follow.

> and is not subscribing to the winfo of the list, new subscriptions might

Not sure I buy this, but I also don't fully understand.

	Paul

---

From: "Henrik Leion" <[email-masked]>
Date: Mon, 21 Jun 2004 10:30:30 +0200

Well, I just thought I'd toss in the idea. I believe that domains will be
small (office or home networks even) and that both inter-domain
subscriptions and resource-list subscriptions will be very common. I was
thinking in these lines:

 - If the ideas with filters, authorization rules and partial presence will
be implemented, how many users can there be on one presence-server? Parsing
xml-docs is quite more time-consuming than just forwarding requests.
 - How large parts of the resource-lists will actually come from the same
presence-server and how much is back-end subscriptions?
 - If subscriptions are to be authorized using watcher-info notification and
XCAP, isn't it a bit boring that it just says "pres.example.com" instead of
at least saying what resource-list your presence is publicated on? Better
yet is that the winfo-file states the subscribers to the resource-lists.

More inline.

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Paul Kyzivat
> Sent: den 18 juni 2004 22:44
> To: Henrik Leion
> Cc: Simple mailinglist

Well, actually I don't know. But what difference is there between an RLS
authenticating itself to a presentity using some "sip:pres.example.com" URI,
than should it use "sip:[email-masked]"?
In either case the presentity have probably never heard of example.com
before.

> having credentials for me.

Yes, I was thinking in the lines of public lists; intranet address-lists,
conferences, discussion groups etc. But I'm under the impression that the
RLS does not use the presentities credentials when creating a back-end
subscription but instead acts on its own, "RLSes acts as a subscriber"
[event-list draft].

> provide results to subscribers of both L1 and L2.

Yes it could.
P.winfo would contain L1 and L2 along with all other watchers that are
interested in the presence of P. If P wants to check who actually subscribes
to L1 and L2, he would consult L1.winfo and L2.winfo.
Another idea is to add a namespace to winfo for resourcelists, now P can see
anybody subscribing to him directly, instead of just knowing that an RLS is
subscribing.
Example, If S1 and S2 subscribes to L1, L2 and S3 also subscribes to P, P
would receive this winfo:

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
		xmlns:rl="urn:ietf:params:xml:ns:resourcelist-watchers">
  <watcher-list resource="sip:[email-masked]" package="presence">
    <rl:list resource="sip:[email-masked]>
      <watcher event="subscribe"
status="active">[email-masked]</watcher>
    </rl:list>
    <rl:list resource="sip:[email-masked]>
      <watcher event="subscribe"
status="pending">[email-masked]</watcher>
    </rl:list>
    <watcher event="subscribe" status="active">[email-masked]</watcher>
  </watcher-list>
</watcherinfo>

In comparison, if the RLS acts as subscriber the watcher info would look
like:
<watcherinfo ...>
  <watcher-list resource="sip:[email-masked]" packeage="presence">
    <watcher event="subscribe"
status="active">[email-masked]</watcher>
    <watcher event="subscribe"
status="pending">[email-masked]</watcher>
    <watcher event="subscribe" status="active">[email-masked]</watcher>
  </watcher-list>
</watcherinfo>

Where the user will have no idea what his presence information will be used
for.
In the former example there is of course no guarantee that the RLS:s in
"another.domain.com" and "athird.domain.com" are telling the truth about the
subscribers, but P will at least have more information when making his
decision.

> potentially *could* subscribe to it?

But that's the whole idea behind presence authorization using winfo-lists,
isn't it? That you can trust the presence server that it only sends your
presence information to those watchers that are marked "active" in your
winfo-file. When new subscriptions come, the presence server will either
allow or disallow it judging from authorization rules, or otherwise set the
subscription-state to "pending" and let the presentity decide.
If you don't trust that the server will act this way in the future, send
less information.

> > information from reaching specific subscribers to the list.

Those present on a resource-list should be allowed to create resource-list
authorization rules appliable to their own presence.
L1 has two subscribers S1a and S1b. P may be authorized to create a rule in
L1.auth that always transforms his presence to appear offline to S1b, whilst
S1a will get P's true presence.
The authorization rules of a resource list should belong to the people on
it, at least in public applications, such as conference lists. But in a
black-list or buddylist application the idea is probably quite stupid.

> Not sure I buy this, but I also don't fully understand.

/Henrik

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jun 2004 05:51:27 -0400

> xml-docs is quite more time-consuming than just forwarding requests.

Its not clear to me how what you are proposing improves performance in 
any way. I guess, to invert that, what is the primary problem you are 
concerned about?

> yet is that the winfo-file states the subscribers to the resource-lists.

When having to choose between pres.example.com and 
sip:[email-masked], you are probably right that the resource list 
is a better identifier. However, the intention of resource lists is that 
the back end subsriptions are authenticated as if they came from the 
user subscribing to the resource list. That is, if bob subscribes to his 
resource list, then the back-end subscriptions would include credentials 
for bob. Section 7.1 talks about using asserted identities for this purpose.

I think that such an approach is really the best model. WHen it works 
that way, the policies that the presentity establishes don't need to 
depend on whether Bob is coming in directly or through a list. The 
presentity doesnt need to know anything about lists, in fact. They 
merely serve as an optimization for performance, rather than as an actor 
in authentication systems.

-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: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jun 2004 10:34:42 -0400

> xml-docs is quite more time-consuming than just forwarding requests.

I too am worried about this. Something that prevents a PS from having to 
send a separate NOTIFY, with customized content, for every direct 
subscriber, including thost that arrive indirectly via a list, would be 
a good thing. But I'm not convinced you have found the right solution.

> yet is that the winfo-file states the subscribers to the resource-lists.

Jonathan addressed this point. I'm with him on it.

> In either case the presentity have probably never heard of example.com

If it were to authenticate as itself, then I agree its likely that 
nobody would grant it authorization. Authenticating as the list itself 
is indeed an improvement over that, but not a great one, because 
authorizing it doesn't give me real control over who receives my 
presence. More on that below.

> subscription but instead acts on its own, "RLSes acts as a subscriber"

Again, Jonathan spoke to this. Using the ultimate subscriber's 
credentials is pretty important.

*If* a list were *known* to be available to only a single subscriber (or 
known list of subscribers I suppose), then authorizing based on 
credentials for the list itself would perhaps be acceptable. (Though 
annoying.) E.g. If I had a pending subscription from:

	sip:[email-masked]

and sip:[email-masked] is indeed a buddy of mine, and I am 
familiar with the example.com rls server and that buddy lists aren't 
shared, then I might be inclined to grant the subscription.

> to L1 and L2, he would consult L1.winfo and L2.winfo.

This is very different than the expected authorization model for 
presence subscriptions. Normally, P will not care about authorized 
watchers in P.winfo. Instead, all it will care about are those that are 
'pending'. They are the watchers that want access to P's presence but 
that have neither been granted nor denied it. User P then either grants 
or denies them access, and never gives them another thought.

In the case of L1 and L2, P has to decide whether to grant access the 
first time the server subscribes on behalf of each. User P can check who 
is currently watching L1 or L2 at that time, but that will say nothing 
about who may watch them at some other time.

> anybody subscribing to him directly, instead of just knowing that an RLS is

This doesn't solve the problem. As a notifier, I don't want to have to 
recognize that a particular watcher is a list and then monitor the 
subscribers of that list to decide moment-by-moment what I am 
comfortable publishing to that set of watchers. And even if I was 
willing to, there would be race conditions so that what I publish could 
go to someone I didn't expect.

For such a system to work at all, it would need to be based on who is 
*authorized* to watch the list, not who is currently watching it. And 
even then, it would be a bad system. The notifier would have to tailor 
the content published to the intersection of what it is willing to make 
available to any of the potential subscribers to the list. That isn't 
going to be very appealing to subscribers that would otherwise be able 
to see more.

> isn't it?

No. See above.

 > That you can trust the presence server that it only sends your

This is way to dynamic for making policy decisions.

> black-list or buddylist application the idea is probably quite stupid.

Well, that would solve some of the problems. But it presents serious 
issues of trust. Why should I believe that I can trust the RLS managing 
L1 to administer my policies?

And mechanistically, I don't think I would want to deal with that kind 
of authorization manually.

It sounds to me like that is a potential optimization that could be 
carried out among a set of mutually cooperating servers that have 
suitable mutual trust arrangements. In that case the user should not 
have to do anything special - the appropriate authorization rules would 
be shared among the servers.

	Paul

---

From: "Henrik Leion" <[email-masked]>
Date: Tue, 22 Jun 2004 10:02:08 +0200

Hmm, I feel we're talking and thinking about different things.
All I'm saying is that it could be useful to see in what context someone
wants my presence info, resource-lists can be used not only to make
subscribing easier - it could help a presentity group subscriptions and
automate authorization.
Resource-lists can be so much more than just a server-sided buddylist (where
end-to-end authorization is undoubtedly best), think discussion-groups,
conferences, games and future event packages.

I'm not suggesting any changes in how subscribers are authenticated, only
that more information is given to the presentity to help him set up
authorization rules (to automate more, not less).
If the presentity would like to challenge a subscription request, he would
still identify the resource-list subscriber as usual.

Consider this scenario:
Bob (sip:[email-masked]) is a member of these resource-lists:
	L1=[email-masked] with 5 subscribers (Bob and his family)
	L2=[email-masked] with 200 subscribers

Bob would like to publish much info to his family, but very limited info to
other Porsche-owners (say online status from his chat-client at home and his
cell phone's geoloc info when he's driving his Porsche). Bob accepts the
risks with sending geoloc info to strangers, because he thinks it's a nice
way of meeting new friends and would like automate the authorization for
members of that list.

But when Bob gets a (back-end) subscription from pres.example.com, challenge
it and finds out it's [email-masked], he still doesn't know if she
owns a Porsche, or if it's his cousin.
If Bob instead gets a subscription from [email-masked] (again
initialized by Alice), he may be content with that, not caring about the
identity of that particular Porshe-owner, and set his policies to
automatically authorize this subscription.

The ideas on writing resourcelist-subscribers in presentity watcher-info and
allowing presentity to write authorization-rules for resource-lists are a
bit far out, I'll admit, but if the resource-lists are made more visible, it
would be possible for those software developers inclined.

Although I never meant to suggest it, the possibility of having the RLS to
authenticate itself, instead of forwarding the authentication request to the
subscriber, is interesting (not annoying). The key is that if the presentity
does not know the subscriber, an authentication would not be very
informative. But if the owner of the list instead says "I will personally
check that every subscriber is entitled to be on this list and kick out
those that misbehave", and the subscribers trust him, they will have the
possibility to automate authorization of strangers with more security.
Check out the game Mogi (http://www.thefeature.com/article?articleid=100501)
that could use Sip this way.

/Henrik

> Sent: den 21 juni 2004 16:35
> To: Henrik Leion
> Cc: Simple mailinglist

Ah, yes. That what the draft says. Thanks

> go to someone I didn't expect
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jun 2004 11:28:15 -0400

Henrik,

I think you are conflating unrelated concepts. The fact that I subscribe 
to the porsche-owners list doesn't make me a porsche-owner.

(In fact I may well aspire to be a porsche-owner by first being a 
porsche-thief!)

So it would be pretty dumb of you to grant me permission to subscribe to 
your presence solely because I have subscribed to the porsche-owners list.

What *might* make sense would be to find a way to share a single list 
for two uses - as a buddy list for subscribing to presence, and as a 
white list for *authorizing* subscription to presence. Then you might 
choose both to subscribe to porsche-owners, and to use the 
porsche-owners list as a white list for granting subscriptions to your 
presence. (There are of course technical issues with accomplishing that.)

	Paul

Henrik Leion wrote:
>>>Well, I just thought I'd toss in the idea. I believe that
>>
>>domains will be
>>
>>> - If the ideas with filters, authorization rules and partial
>>
>>presence will
>>
>>>be implemented, how many users can there be on one
>>
>>presence-server? Parsing
>>
>>> - How large parts of the resource-lists will actually come
>>
>>from the same
>>
>>> - If subscriptions are to be authorized using watcher-info
>>
>>notification and
>>
>>>XCAP, isn't it a bit boring that it just says
>>
>>"pres.example.com" instead of
>>
>>>at least saying what resource-list your presence is publicated
>>
>>on? Better
>>
>>>authenticating itself to a presentity using some
>>
>>"sip:pres.example.com" URI,
>>
>>>Yes, I was thinking in the lines of public lists; intranet
>>
>>address-lists,
>>
>>>conferences, discussion groups etc. But I'm under the
>>
>>impression that the
>>
>>>interested in the presence of P. If P wants to check who
>>
>>actually subscribes
>>
>>>Another idea is to add a namespace to winfo for resourcelists,
>>
>>now P can see
>>
>>>anybody subscribing to him directly, instead of just knowing
>>
>>that an RLS is
>>
>>>subscribing.
>>
>>>But that's the whole idea behind presence authorization using
>>
>>winfo-lists,
>>
>>>isn't it?
>>
>>No. See above.
>>
>>>allow or disallow it judging from authorization rules, or
>>
>>otherwise set the
>>
>>>Those present on a resource-list should be allowed to create
>>
>>resource-list
>>
>>>L1 has two subscribers S1a and S1b. P may be authorized to
>>
>>create a rule in
>>
>>>L1.auth that always transforms his presence to appear offline
>>
>>to S1b, whilst
>>
>>>The authorization rules of a resource list should belong to the
>>
>>people on
>>

---

From: "Henrik Leion" <[email-masked]>
Date: Wed, 23 Jun 2004 09:42:11 +0200

I give up.
But I'm still convinced that SIP should have the option to have less
security (security can be provided by other means) for the benefit of
automatically authorize subscriptions from a dynamic group as a group
instead of per user.
Since the geopriv Common Policy only allows one uri element per rule,
presentities will have to create one rule per subscriber.

In the Porsche example, Bob and the other presentities would need to create
200 rules each, and add new as new members joined. By hand.
Changing the From-header in the resource-list subscriptions seemed like a
simple fix. One rule each.

But if resource-lists will only be used for buddylists, I guess it's ok.

/Henrik

PS.
About that car thief. He couldn't be avoided in the Porsche discussion group
even if all subscriptions were labelled pres.example.com and the
presentities authorized every single subscription by hand. The presentities
would know the true identity of all members, but they still wouldn't know
who took their cars.

> Sent: den 22 juni 2004 17:28
> To: Henrik Leion
> Cc: Simple mailinglist
> > Check out the game Mogi
> (http://www.thefeature.com/article?articleid=100501)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2004 15:55:36 -0500

There is one very fundemental point of the event list draft that seems 
to be missing from this discussion:

The draft decscribes normative behavior on how one subscribes to a 
resource list, how the RLS constructs the aggregate state data, etc. It 
very explicitly does _not_ specify normative behavior on how the RLS 
aquires the event state for each list member. The use of back-end 
subscriptions is simply one way you could do this. We have pointed out 
some issues related to subscriber identity, but we have not stated 
requirements about it.

There is nothing in the draft that _forbids_ the RLS from subscribing on 
its own behalf.

Henrik Leion wrote:

>>>Resource-lists can be so much more than just a server-sided
>>
>>buddylist (where
>>
>>>I'm not suggesting any changes in how subscribers are
>>
>>authenticated, only
>>
>>>If the presentity would like to challenge a subscription
>>
>>request, he would
>>
>>>	L1=[email-masked] with 5 subscribers (Bob and
>>
>>his family)
>>
>>>Bob would like to publish much info to his family, but very
>>
>>limited info to
>>
>>>other Porsche-owners (say online status from his chat-client at
>>
>>home and his
>>
>>>risks with sending geoloc info to strangers, because he thinks
>>
>>it's a nice
>>
>>>But when Bob gets a (back-end) subscription from
>>
>>pres.example.com, challenge
>>
>>>it and finds out it's [email-masked], he still
>>
>>doesn't know if she
>>
>>>If Bob instead gets a subscription from
>>
>>[email-masked] (again
>>
>>>The ideas on writing resourcelist-subscribers in presentity
>>
>>watcher-info and
>>
>>>allowing presentity to write authorization-rules for
>>
>>resource-lists are a
>>
>>>bit far out, I'll admit, but if the resource-lists are made
>>
>>more visible, it
>>
>>>Although I never meant to suggest it, the possibility of having
>>
>>the RLS to
>>
>>>authenticate itself, instead of forwarding the authentication
>>
>>request to the
>>
>>>subscriber, is interesting (not annoying). The key is that if
>>
>>the presentity
>>
>>>informative. But if the owner of the list instead says "I will
>>
>>personally
>>
>>>>>subscriptions and resource-list subscriptions will be very
>>
>>common. I was
>>
>>>>>thinking in these lines:
>>>>>
>>>>>yet is that the winfo-file states the subscribers to the
>>
>>resource-lists.
>>
>>>>>Well, actually I don't know. But what difference is there
>>
>>between an RLS
>>
>>>>>>*my* buddy list) having credentials for my buddy list is no
>>
>>easier than
>>
>>>>>>Well, maybe it *could* but that sounds really cumbersome,
>>
>>expensive, and
>>
>>>>>>not especially reliable. Can I ever safely decide what to
>>
>>disclose based
>>
>>>>>winfo-file. When new subscriptions come, the presence server
>>
>>will either
>>
>>>>>If you don't trust that the server will act this way in the
>>
>>future, send
>>
>>>>>less information.
>>>>