Re: Presence service identifiers

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.

> (b) make the source of the <notify> element be the
> presence service that provides the information.

Yes.  This is the key change I propose.

> (I must confess, I'm not entirely recollecting what purpose was
> previously served by 'entityInfo' in the original document, but I
> think it may have been a hook for providing additional information
> about the entity whose presence information is provided.  I can't
> offhand think of a reason that it's loss would be a problem.)
> 
> 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.

> 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.

> At this point, I've just re-read your longer message - I think I'm
> getting closer to understanding but I still think the text needs
> improving.  I think that giving a clear (and brief) discussion of
> authorization (access control) in terms of the from: header, and
> completely separately discussing the use certificates and other
> paraphernalia to authenticate/validate the from: header would be
> helpful here.
> 
> I find myself in a peculiar position here:  I think I find your
> suggested changes are reasonable, but I'm still not fully convinced I
> understand them so I cannot be sure.  Hence this  picking over the
> wording ahead of formally agreeing with the intent.

I welcome your picking over the words as this seems to me to be the
best way advance the description of the idea.  I don't seem to be able
to do so on my own.

John



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