Re: Sub/Not Security, Presence service identifiers

I thought about your many fine questions.  I believe there are three
essential elements required to enable notification authentication.

1. Presence services must have an identity that distinguishes them
   from all other subjects which can be derived from a presentity's
   URI.

2. A presences service must use a common format that can be signed.

3. The content that is signed must include a timestamp that records
   the time at which the notification operation was initiated.  This
   prevents replay attacks.

Can anyone think of some more essential requirements?

Point 2 is already address by the PIDF.  Point 3 was discussed in
another posting.  I would like to focus only on the issue of presence
service identifiers in this posting, and avoid the issue of wrappers.

I note there is opposition to my trick of reserving PRES URI's with a
local part of "notifier" to be presence service identifiers.  I am not
wedded to this trick.  Here are some alternatives for you to consider.

We could define another scheme, the PRESSRV scheme in which the scheme
specific part is required to be a domain name only.  Thus the presence
service at mitre.org would be identified by:

        pressrv:mitre.org

We could also use the convention that PRES URIs that have only a
domain name in their scheme specific part are to be interpreted as
presence service identifiers.  Thus the presence service at mitre.org
would be identified by:

        pres:mitre.org

> - I'm not really clear why we need to ascribe presence identities
> (with usernames) to presence services - they are not presentities
> themselves.

The reason presence services need identifiers is because they can
initiate operations, and object that have those operations invoked on
them need to authenticate the invoker.  The trick of using a presence
identity with a username was just a coding trick.  I am open to
alternative ways of identifying presence services.

John



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