[Standards-JIG] RE: pubsub: affiliations and subscriptions

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed Feb 22 12:07:24 UTC 2006


Interresting approach, indeed. 

But I support Ralph and Bob in saying that mixing access control
(affiliation) and subscription is messy. 
Affiliation is all about making sure the right party is performing the
proper operation. 
Susbcription is about defining the 'interest' (i.e. the what?) and the
destination of the notification (the where?).

The issue comes from the way JIDs (i.e. communication handles) are used to
convey authorization semantic. That may work to a certain extent in the
context of an IM server, but become a little stretched for additional
services such as PubSub or MUC.

Recognizing that affiliation and subscription (to pubsub or a room) are two
different concerns will help finding an appropriate answer.

I believe that the way to convey the 'membership' to a particular
affiliation must be opaque to the subscriber, maybe using some kind of token
to allow the implementation to reconcile affiliations. Gaston's approach
could then be used in order to convey this token instead of JID in the owner
attribute of the <subscribe/>. 

Using a separate element to describe affiliation would in principle be
compatible with existing implementations, as they should not giver any
meaning to unknown extensions. This approach would also pave the way for a
more appropriate approach to 'security' than just making sure JIDs are the
same in the subscription and the info-query....

Jean-Louis



-----Original Message-----
Message: 3
Date: Tue, 21 Feb 2006 18:27:55 -0300
From: "Gaston Dombiak" <gaston at jivesoftware.com>
Subject: [Standards-JIG] Re: pubsub: affiliations and subscriptions
To: standards-jig at jabber.org
Message-ID: <dtg0kv$57m$1 at sea.gmane.org>

Hey guys,

I think that there is a previous problem that we need to figure out before 
discussing how affiliations and subscriptions should be exposed. IMHO, the 
main issue here is to figure out how should the 1-n relationship between 
affiliations and subscriptions be built. In other words, how does the pubsub

service know that a new subscription request belongs to an existing 
affiliate and not to a new or other existing affiliate.

Let me give you an example to clarify what I'm trying to say here. Following

with the example provided by StPeter I will change the sequence in which the

subscriptions were made.

1. A subscription to JID = juliet at capulet.com/balcony is sent to the pubsub 
service (with SubID = sub2)
2. A subscription to JID = juliet at capulet.com/chamber  is sent to the pubsub

service (with SubID = sub3)
3. A subscription to JID = juliet at capulet.com  is sent to the pubsub service

(with SubID = sub0)

When the first subscription request is received, the pubsub service creates 
a new affiliation of type none and a new subscription. Ralph said that he 
would use the bare JID (e.g. juliet at capulet.com) as the entity that now has 
an affiliation with the node and the subscription should keep using the 
provided JID (e.g. juliet at capulet.com/balcony). But as StPeter said using 
the bare JID might be correct for the IM world (i.e. human being users) but 
not fully correct when dealing with other type of entities.

When the second subscription request is received, the pubsub service has to 
find out who is the entity that is trying to subscribe to the node. As we 
said before, Ralph said that the bare JID can be used so we now know that 
the new subscription belongs to the same entity that made the previous 
subscription (e.g. juliet at capulet.com). This is fine for the IM world but 
not for other cases.

For the third subscription request the same steps we used for the second 
subscriptions are used. Therefore, if we were using the bare JID as the way 
to identify entities then the service will end up with only one affiliation 
for juliet at capulet.com and 3 subscriptions to different JIDs.

As you may have realized the problem is that we cannot trust that using the 
bare JID of the JID that is going to get the event notifications is the 
right way to identify the real entity that is behind the three 
subscriptions. IMHO, the options are 1) inferring who the affiliate is or 2)

let the subscriber provide who the real entity/affiliate is thus making the 
relationship explicit. I think that using an explicit mode does not have any

margin of error.

So my recommendation is to add a new attribute to the <subscribe> element 
that specifies the JID of the entity that owns the subscription. If the 
attribute is not specified then the JID used for the subscription is assumed

to be the JID that uniquely identifies the entity. This idea should also 
work well for previous versions.

Examples of how this may work.

Example 1. Entity subscribes to a node (entity JID = subscription JID)
<iq type='set'
    from='francisco at denmark.lit/barracks'
    to='pubsub.shakespeare.lit'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe
        node='blogs/princely_musings'
        jid='francisco at denmark.lit'/>
  </pubsub>
</iq>

Example 2. Entity subscribes to a node (entity JID that owns the 
subscription is made explicit)
<iq type='set'
    from='francisco at denmark.lit/barracks'
    to='pubsub.shakespeare.lit'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe
        node='blogs/princely_musings'
        owner='francisco at denmark.lit'
        jid='francisco at denmark.lit/PDA'/>
  </pubsub>
</iq>

A pubsub service that is not very concerned about security might allow the 
owner to have a different bare JID to the subscription bare JID. This 
scenario might be useful for users that have different accounts in many 
servers. But the JEP may recommend that pubsub services should validate that

the bare JID of the owner should match the bare JID of the subscription JID.

Regarding the way the pubsub service should expose affiliations and 
subscriptions I would prefer to split them and expose them as different 
things. This would make things simpler but may break existing 
implementations. But a consequence of  copying the affiliation for each 
subscription is that the node owner might potentially try to set a different

affiliation in each subscription for the same entity. The service would need

to validate this case and IMO the API is also confusing and error prone. And

the way to fix that is to make the service more complex.

Regards,

  -- Gato


"Bob Wyman" <bob at wyman.us> wrote in message 
news:089e01c634f0$7030f590$be43fa0a at BOBSLAPTOP...
> On Fri, Feb 17, 2006 at 09:22:30PM -0700, Peter Saint-Andre wrote:
>> So my conclusion is that it's best to be a bit more verbose and
>> represent one "affiliate" for each combination of affiliation and
>> subscription. This is more verbose but, I think, the safest approach.
> I agree. Given the way that current systems work and what we have in
> the current protocol, we must use the more verbose approach and support
> having multiple subscription-specific affiliations to a single node. The
> current mechanism for getting a list of active subscriptions is to list
> affiliations. It would be kind of violent to modify that now...
>
> I also agree with Ralphm's suggestion that mixing affliations and
> subscriptions is messy. I have never liked this "affiliation" business. It
> seems to combine too many concepts into a single messy framework. What I
> would much prefer is a general access control mechanism for operations on
> nodes. Doing things such as listing subscriptions shouldn't require that
> clients get exposed to "affiliation" information which is basically just
> access control info on nodes. When I'm working with subscriptions, I don't
> care about nodes... I only care about nodes when I'm creating 
> subscriptions.
>
> bob wyman
>
>
>
> 




More information about the Standards mailing list