Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Mar 2001 18:12:24 -0500

Good - meat for the discussion in Minnesota then.

Please comment on the thread when you can.
James/Jonathan - did I summarize your conclusion correctly?

The questions in my last paragraph still stand, and should
be addressed before we dive on the topic.

RjS 

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 4:28 PM
> To: Robert Sparks
> Cc: [email-masked]
> Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF
> agenda)
> 
> 
> Uh, I do not recall any such consensus. We find that QAUTH is actually
> quite useful.
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: Wednesday, March 14, 2001 2:15 PM
> > Cc: [email-masked]
> > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE 
> BoF agenda)
> > 
> > The consensus at the end of this sub-thread, as I understand
> > it, was to abandon the idea of QAUTH as specified in qauth-00
> > and look for other mechanisms (Jonathan has proposed subscribing
> > to subscription attempts as an alternative)to obtain authentication.
> > 
> > So, QAUTH is abandoned and new implementors should not pursue it.
> > 
> > Where/when should work on replacing its functionality take place?
> > 
> > I don't see that it fits under the current SIMPLE charter (feel free
> > to argue with me). Should we table the concept for possible future
> > consideration then, or formally boot it to the sip-events arena? (A
> > generalized solution there would be valuable).
> > 
> > RjS
> > 
> > > -----Original Message-----
> > > From: James Undery [mailto:[email-masked]]
> > > Sent: Wednesday, February 28, 2001 10:18 AM
> > > To: Jonathan Rosenberg
> > > Cc: [email-masked]
> > > Subject: RE: [Simple] SIMPLE BoF agenda
> > >
> > >
> > >
> > >
> > > On Wed, 28 Feb 2001, Jonathan Rosenberg wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: James Undery [mailto:[email-masked]]
> > >
> > > > > I really think using the current QAUTH proposition is far
> > > > > from ideal and if it
> > > > > can't be improved something else (non SIP based) should be
> > > > > considered. The
> > > > > transaction time-out issue is a real killer, I'd be
> > > > > interested in comments on
> > > > > using Subscribe and Notify for pull mechanism (my only
> > > > > concern at the moment is
> > > > > horrendous recursion).
> > > >
> > > > Well, there is a way to use SUB/NOT that would allow us to
> > > converge the
> > > > push/pull mechanisms.
> > > >
> > > > Consider the set of subscribers to a presentity as a piece
> > > of dynamically
> > > > changing state. Call this state the "subscription list for
> > > presentity A". I
> > > > can easily imagine that it is possible for entities
> > > (typically, presentity
> > > > A) to subscribe to this state. So, when it changes (such as
> > > when a new
> > > > subscriber X asks for a subscription to A), this causes a
> > > NOTIFY to be sent
> > > > to anyone watching "subscription list for presentity A" -
> > > probably A. Now,
> > > > at this time, A can choose to push a new policy list to the
> > > server. This new
> > > > policy list is one which blocks X. Whenever a presence
> > > server receives a new
> > > > policy, it automatically runs that policy against existing
> > > subscriptions.
> > > >
> > > > Note that we even proposed a data format for representing
> > > the state of
> > > > "subscription lists". See
> > > >
> > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-imp
> > p-watcherinfo-
> > > 00.txt.
> > >
> > > So, lets assume that we use a CPL variant to express 
> policy. Assume
> http
> > is
> > > used to push these policies into the server. The flow would look
> like
> > this:
> > >
> > >
> > > subscriber               presence server                  
> presentity
> > >
> > > SUB
> > > ------------------------------>
> > >
> > > 202 OK
> > > <------------------------------           NOTIFY w/ subscription
> state
> > >                               ---------------------------------->
> > >                                            200 OK
> > >                               <----------------------------------
> > >                                    http POST w/ CPL
> > >                               <----------------------------------
> > >                                    200 OK
> > >                               ----------------------------------->
> > >
> > > In this way, policy information is always passed using a single
> > mechanism,
> > > but it is triggered using a NOTIFY.
> > >
> > 
> > I think this is a better solution as with a properly 
> configured policy
> > list/script it would address info leakages (for those concerned with
> > that sort of thing) by defaulting to display offline until the
> subscriber
> > was accepted.
> > 
> > James Undery
> > 
> > 
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: James Undery <[email-masked]>
Date: Thu, 15 Mar 2001 09:13:07 +0000

Comments inline.

> > Uh, I do not recall any such consensus. We find that QAUTH is actually

I'd agree there was no definite consensus, however, I'd disagree QAUTH is
useful.

> > > to subscription attempts as an alternative)to obtain authentication.

The only thing I'd add is when the presentity is notified of a change in the
subscriptions to itself it may then supply a new document describing its
authentication policy to the presence server.

> > > generalized solution there would be valuable).

I am all for a CPL style language to control generic sip event subscriptions
and also agree this should be done outside the SIMPLE WG.

James Undery