Subject: [Sipping] Questions and comments on on-demand authorization draft

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 02:06:40 -0500

Some questions and comments on:
http://www.ietf.org/internet-drafts/draft-trossen-sipping-ondemand-00.txt

Firstly, to reiterate a question Aki had asked earlier - in what way 
is this not reactive authorization? As far as I can tell it is, 
combined with the desire to provide time limits on the authorization, 
and to try and provide some kind of package-independent authorization 
mechanism. Is that right?

If so, its not clear to me that it really is a good idea to have 
authorization policies and access controls that are independent of the 
package. For almost anything beyond the basic black/white list, the 
details of the authorization policies are one of the main things that 
really varies from package to package.

If the aim is to provide a common mechanism for a basic black/white 
policy independent of the package - I think we can accomodate that 
with a bit of extra text and some hooks in the current xcap-auth spec. 
  In particular, the spec can state that the general structure is 
package independent, and then the <accept> permission has an attribute 
called package that defines the package for which the acceptance is 
granted. The default would be presence.

To provide time limitations to access, you can either remove the 
permission at the appropriate time, or else one can define an xcap 
authorization extension that defines time windows. That has already 
been done in geopriv, btw.

I am not sure that I see what is gained from trying to move towards a 
ticket based system, which appears to be (at least by my reading) the 
preference of the authors. There are a lot of holes that would need to 
be filled in for that to work - much more than getting the 
functionality into xcap.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Nov 2003 11:53:38 -0500

This is clearly a very early discussion document, rather than 
necessarily a way forward. The principal issue, I believe, is one of 
getting the timing right. If I hand you a token, you can immediately 
access the resource as soon as you have the token. If I need to update a 
permissions file (e.g., XCAP), I need to tell you "please wait some time 
before you try accessing the resource, to make sure you don't get 
rejected" or you would have to have a feedback mechanism that says "ok, 
please try now, you're in the list".

I'm not sure whether this synchronization problem is sufficiently large 
in practice to warrant a new mechanism. The document tries to raise that 
discussion.

Jonathan Rosenberg wrote:

> Firstly, to reiterate a question Aki had asked earlier - in what way is 
> this not reactive authorization? As far as I can tell it is, combined 
> with the desire to provide time limits on the authorization, and to try 
> and provide some kind of package-independent authorization mechanism. Is 
> that right?
> 
> policy independent of the package - I think we can accomodate that with 
> a bit of extra text and some hooks in the current xcap-auth spec.  In 
> particular, the spec can state that the general structure is package 
> independent, and then the <accept> permission has an attribute called 
> package that defines the package for which the acceptance is granted. 
> The default would be presence.
> 
> authorization extension that defines time windows. That has already been 
> done in geopriv, btw.
> 
> be filled in for that to work - much more than getting the functionality 
> into xcap.
> 
> Thanks,
> Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Nov 2003 02:18:30 -0500

> please try now, you're in the list".

With rfc3265, we have exactly this capability. The NOTIFY can indicate 
that the subscription state has moved from active to pending.

-Jonathan R.