Re: Presence service identifiers

Graham,

Point by point responses are inline, however, here is how I would
summarize the requirements on identifiers to enable end-to-end
authentication.

* There are two kinds of subjects, people and presence services.

* Each subject has a number of identifiers, called principals.

* No principal should identify more than one subject.  Therefore,
  people and presence services should have distinct identifiers.

* Given a PRES URI that names a presentity, a client should be able to
  construct the presence service principal that provides subscription
  service for the presentity.

The last point is necessary so that a client can be sure the proper
presence service is providing notifications, and in particular,
determine that an unauthorized person is not providing presence
service.

I don't care too much about the particular details of the function
used to construct a presence services identifier from a presentity.  In a
previous post, I suggested the mapping in which the presence service's
identifier was generated by replacing the local part of the PRES URI
with the string "notifier", but any easily computed function will do.

Graham Klyne <[email protected]> writes:

> At 08:13 PM 7/26/02 -0400, John D. Ramsdell wrote:
> >Graham Klyne <[email protected]> writes:
> >
> > > OK, I read through that.  Let's see if I'm separating the right
> > > principle (sic) from the details...
> > >
> > > First, what you propose:  (a) move details of the principal whose
> > > presence information is provided into the <presence> structure,
> > > replacing 'entityInfo' -- previously this was the target in the
> > > <notify> element;
> >
> >No.  I propose no change to the PIDF format.  I'm just using the PIDF
> >as is currently defined.  This quote is from the PIDF document V 05,
> >Section 4.1.1:
> >
> >    The <presence> element MUST have an 'entity' attribute. The value of
> >    the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
> >    this presence document.
> 
> Oops, of course!  I was getting confused by the use of XML as an
> illustrative syntax in the CPIM document.  Now that PIDF is a defined
> format (it wasn't when the CPIM document was first drafted), I expect
> the CPIM draft should be updated -- at least to more clearly separate
> the PIDF content from the service header information.
> 
> > > (b) make the source of the <notify> element be the
> > > presence service that provides the information.
> >
> >Yes.  This is the key change I propose.
> 
> OK, I think I see.  And that seems reasonable to me.
> 
> Now where does this leave interaction with IMPP systems that don't
> explicitly identify the presence service as a distinct entity?   You
> mentioned a "reserved" name previously, but I'm uneasy about that.
> Since the main purpose of this name is to be a token that is bound to
> a signature (e.g. by a certificate), does it really matter what name
> is used for this?  Seems to me what matters is that the identity is
> (a) properly recognized by a local authorization mechanism, and (b)
> properly bound to an authenticating signature.

And that clients consuming presence information can easily construct
the presence service's identifier associated with a given presentity.

> What I'm suggesting here is that the allocation of the presence
> notification service name (or whatever entity that signs the
> notifications) can be a local administrative matter, and there's no
> need to say any more than that it exists.  Then, I think it would be
> easy enough for each CPIM-conformant IMPP protocol to indicate whether
> or not a standard identifier form or an arbitrary local choice is
> used.

It can't be a local matter, otherwise, how do clients know which
identifiers identify presence services, and which identify people?
How do they know they are receiving information from the the right
presence service?

> (e.g. for APEX, I think there's a natural way to allocate a service
> name, but for (say) SIMPLE or Jabber I'm not so sure that's the case.
> I'm trying to avoid imposing a naming conventionthat might not fit
> equally comfortable to all protocols.)
> 

Does anyone know if APEX has a problem with the proposed naming
convention?

> > > The goal seems to be to allow the authenticated entity to be separate
> > > from the authorized entity?
> >
> >The goal is to provide the subject that invokes a notify request--a
> >presence service--with an identity.  A signing subject should be the
> >only service that can prove it is authorized to use the identity
> >because only it possesses the appropriate private key.
> 
> Yes, that seems to follow from above, now.
> 
> Let me see if I can summarize this in a few bullets:
> 
> + each notification identifies the presence service that generated it.
> 
> + the presence service identifier is in general distinct from any
> endpoint (client) identifier.
> 
> + the presence service identifier is associated with authority to
> deliver presence notification to any party (watcher) who has requested
> such notification - the authorization (access control) mechanism is
> not specified, but is presumed to be locally defined by the watcher's
> domain.
> 
> + the presence service identifier (and associated keys) may be used in
> cryptographic signatures that authenticate the presence notification
> information to the watcher.
> 
> Close?

Yes this is close.  Do you like the summarization I gave at the
beginning of my note?

> (Note:  part of what I am trying to tease out here is that even whenh
> authentication is provided end-to-end, access control is still a
> matter for local administrative control.  Otherwise, we get into a
> mess of defining global access control mechanisms as well, which I
> think we'd do well to avoid.)
> 
> > > And if I'm understanding correctly, one advantage of your proposal is
> > > that it means the same authorization framework applies to both IM and
> > > presence notification?
> >
> >Yes.  And it is obvious how one would extend this framework to cover
> >subscription requests once a common format is agreed to.
> 
> Ah, yes. (If ;-)
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <[email protected]>



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