RE: Sub/Not Security, Presence service identifiers

> Presence information could have been generated a week ago because
> I went on holiday and haven't updated my presence info from
> saying "On holiday". You subscribe to my presence info today. You
> get a week old presence info. Does that mean my presence info
> cannot be authentic?
>
> Timestamp of when the notification is sent makes more sense to me.

It's OK to have a timestamp for when a notification is sent. The question is
whether the notification including that timestamp has to be signed by the
presence service, so as to prove that the timestamp is correct.

There are two ways to get a notification: the "first notification" that's
the information provided in response to a new subscription, and a "true
notification" that reflects a change in presence information for an existing
subscription.

If you are getting a first notification in response to starting a
subscription, it's OK if the signed timestamp in the presence info is
"old" -- it might have really been a long time since it changed. A timestamp
on the notification is not crucial here as long as you're getting a timely
notification (shortly after the subscription request), which you can
determine just by the watcher's local time.

If you are getting a true notification on an existing subscription, you
should be suspicious if there's a big gap between the timestamp in the
presence info and the current time -- because nominally the notification is
triggered by the change. Certainly if you got a purported true notification
that had week-old data, you would conclude that there was either a bug in
the service or an attack taking place.  Again, you don't really need a
signed timestamp on the notification, you can detect this problem based on
the watcher's local time.

Am I overlooking some other scenario in which a signed notification
timestamp would be helpful?

--Mark




  [reminder: [email protected] for non-technical discussions, please]