RE: On the need for presence service identifiers

I guess I'm a little confused here because your conceptual model and terms
don't seem to align with RFC 2778.

In particular, I can't tell whether you're concerned about principals or
presentities going away. Even if a principal is "going away for a week",
that principal can still arrange for a corresponding presentity to supply
hourly refreshes of their "I'm away" information if that's what they want.
I'm not saying that everyone's implementation will support that, but there's
no logical impediment to having that functionality if it's desired.

From the perspective of the presence service, the presentity is the source
of the presence information, and the part of the system doing the signing of
that presence info... isn't it?

--Mark


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Thursday, August 22, 2002 8:41 AM
> To: Mark Day
> Cc: [email protected]
> Subject: Re: On the need for presence service identifiers
>
>
> This proposal has some interesting properties, but I don't understand
> how presence information is refreshed.  Suppose the standard lease
> duration is one hour, and the person that owns the presentity goes
> away for a week.  That person can no longer sign presence information
> updates.  The alternative is that the presence service signs the
> messages, but your note suggests you do not intend this.  Who signs
> presence information when the person is away?
>
> John
>
> "Mark Day" <[email protected]> writes:
>
> > I think I understand this, and agree that it is a potential
> vulnerability. I
> > disagree about its likely practical importance and the proposed
> solution.
> >
> > If I were particularly concerned about foiling this attack, I
> would change
> > the timestamps in the presence information to leases -- they
> would have a
> > start-time and an end-time, or a start-time and a duration. The
> presentity
> > could choose the length of lease so as to trade off the interval during
> > which this attack is possible vs. the inconvenience of refreshing
> > otherwise-unchanged presence information whose lease has expired.
> >
> > I believe this approach would solve the identified problem
> without the need
> > to introduce the machinery to name, authenticate, etc. etc. the presence
> > services and individual notifications.  But I may have
> overlooked something,
> > so I'd welcome correction.




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