Subject: RE: [Sipping] Consent discussion

From: [email-masked]
Date: Sun, 13 Mar 2005 18:48:54 +0200

Hi,

My understanding of the use cases for the consent mechanism are these (if this is too narrow, I hope someone points that out):

1. Authorizing retargeting at user's home proxy
2. Authorizing retargeting at a "URI list service" element

I agree that these are two pretty different cases in terms of e.g. granularity of permissions, and the a priori association between the user/UA and the element enforcing the authorization.

The problem in the current consent framework is that it does not make distinction between these two cases, and relies on SIP PUBLISH as one-size-fits-all solution.

To me it seems that home proxy authorization should be possible at a reasonable high granulariy, perhaps along the lines of how presence authorization is done. A useful thing is that the user already has a security association with its home domain, and it would also be reasonably easy for a UA to learn e.g. a URI which provides the access for the manipulation of the auth permissions. In this case it is important for the user to be able to set permissions in advance of communication attempts. Also, things like <domain> matching are useful.

On the other hand the granularity for permissions given for a URI list service element are pretty coarse. In my opinion it is enough just to be able to express whether that element is allowed to retarget requests to the user, _regardless_ of the sender. (I assume that the URI list service would have a separate authorization on who is allowed to send requests to it in general.)

Based on these considerations, I would propose:
1. Home proxy authorization would be based on Common Policy and the must-implement protocol for manipulation would be XCAP. 
2. URI list service authorization would be a simple yes/no type of permission, that could be set by sending a SIP request (perhaps as proposed by Aki below) to a corresponding URI. This would be the default functionality, which obviously could be extended to cover e.g. senders, methods etc. should the need arise.

With this kind of mechanims I would find consent framework extremely useful and I think there would be a stong insentive to really deploy it! (I have been really sceptical about it thus far...)

Regards,
	Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Paul Kyzivat
> Sent: 11 March, 2005 01:13
> To: Niemi Aki (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Sipping] Consent discussion
> 
> 
> 
> 
> Aki Niemi wrote:
>  > Inline.
>  >
>  > ext Paul Kyzivat wrote:
>  >
>  >> Gonzalo pointed out in the meeting today that consent is 
> ultimately
>  >> held by the node that needs it, rather than a node 
> associated with the
>  >> grantor. OTOH, buddy lists, acls, or other forms of 
> authorization are
>  >> held by a node associated with the grantor. The latter 
> require much
>  >> more structure.
>  >>
>  >> These are distinct and potentially complementary mechanisms.
>  >
>  > Good point. I agree.
>  >
>  >> When a CONSENT request makes its way to the AoR for which 
> consent is
>  >> requested, it is quite reasonable to check it against an 
> authorization
>  >> list there. If it matches, then consent can be granted 
> automatically,
>  >> without bothering the user. If the request isn't 
> automatically granted
>  >> this way then it is queued up to the user for explicit 
> confiration.
>  >
>  > Yes, I would go even further. It really looks like an authorization
>  > policy is needed for incoming requests. The natural place 
> is the home
>  > proxy server which is anyway the policy point with respect 
> to what an
>  > AoR will receive. For example, CPL is one such policy already.
>  >
>  > First thing that comes to mind is to use the common-policy 
> authorization
>  > policy framework, along with an XCAP usage.
> 
> Yes, I agree. It was my intent that this fit into whatever general
> mechanism was in place for incoming requests. Guess I wasn't 
> clear about
> that.
> 
>  >> If a consent request makes it to the user, the user has 
> the option to
>  >> just accept or reject it, or the user may also decide to 
> update its
>  >> own authorization lists so that future similar consent 
> requests are
>  >> automatically granted.
>  >
>  > Yes, and such authorization rules would benefit immensely from the
>  > ability to use wildcards, for instance.
> 
> Yes. It was my assumption that the general authorization 
> framework would
> be rich in this regard. And so it will require a 
> correspondingly richer
> mechanism for managing the authorization policy, such as xcap.
> 
>  >> The manipulation of the user's authorization lists can be 
> done with
>  >> XCAP while consent is done with PUBLISH.
>  >
>  > Agreed. Although I'd much prefer a new method pair, GRANT 
> and REVOKE for
>  > granting consent and removing it. PUBLISH is very much tied to the
>  > events framework, and things like etags apply to only a particular
>  > publication, which won't work well in the concent 
> framework. I might
>  > want to grant concent from a different UA from where I revoke it.
> 
> Whatever - I don't feel strongly about this. Either way it is a very
> lightweight mechanism, both in terms of implementation and network
> resources.
> 
> 	Paul
> 
>  > Cheers,
>  > Aki
>  >
>  >>     Paul
>  >>
>  >> _______________________________________________
>  >> 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
>  >>
>  >
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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