Adding notifier authentication to CPIM

Dave,

I carefully studied the CPIM draft 02 document.  I have compiled a
list of changes that I believe are needed to add notifier
authentication to CPIM.

1. In Section 3.1 titled "Overview of the Presence Service"

The example notification should be changed to include a source attribute:

          <notify watcher='pres:[email protected]'
          target='pres:[email protected]'
          source='pres:[email protected]'
          transID='1234'>
          <presence entityInfo='http://www.example.com/fred/'>
          <tuple destination='im:[email protected]' status='open'
          />
          </presence>
          </notify>

2. In Section 3.4.2 titled "The Notify Operation"

The source parameter should be described as follows


          *    The source parameter specifies the PRESENCE SERVICE
               that is providing the presence information;

I suggest inserting this text between the text for the target and the
transID parameter.

3. In Section 4.3.2 titled "Presence Service"

All of the text can now be placed with something like:

          The common data format for presence information is PIDF,
          therefore, the privacy of presence information can be
          protected using end-to-end encryption.  The identity of the
          presence service providing presence information can be
          authenticated using digital signatures.  This protects a
          watcher from being spoofed.

4. In Section 8 titled "The Presence Service DTD"

Add the following attribute declaration.

          <!ATTLIST notify source %presentity; #REQUIRED>

5. In Appendix B titled "Message/CPIM for Presence"

Describe the MIME Type "message/CPIM-PIDF" and explain that the source
attribute maps to the 'From' header, the watcher attribute maps to the
'To' header, and the target attribute is given by the entity attribute
of the presence element in the PIDF enclosure.

6. Someplace in the document, there needs to be a place that describes
   how the specification supports strong authentication for
   operations.  I'm not sure where to put it, or exactly what to say
   at this time, but you may find the following text useful.  I'll
   keep thinking about the missing text too.

The specification provides a means for identifying the originator of
each operation.  The 'From' header of each operation contains a URI
that identifies the originator.  A client or server may choose to
simply trust the contents of the 'From' header of every request, and
make access control decisions based on it.  In this case, no digital
signatures are required.

Alternatively, a client or server may designate a set of URIs as
sensitive.  When a client or server receives a request that claims it
is from one of these sensitive URIs, it should reject the request
unless the originator proves it has the right to identify itself with
the given URI.

Digital signatures are used for the proof.  A signed request should
include a certificate that links it to the URI in the 'From' header.
For example, when using X.509 Version 3 Certificates [X.509V3], the
URI in the 'From' header must be one of the certificate's Subject
Alternate Names.



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