Subject: [Sipping] Consent discussion

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2005 12:10:21 -0500

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.

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.

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.

The manipulation of the user's authorization lists can be done with XCAP 
while consent is done with PUBLISH.

	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

---

From: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 00:28:59 +0200

Inline.

> These are distinct and potentially complementary mechanisms.

Good point. I agree.

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

> authorization lists so that future similar consent requests are 

Yes, and such authorization rules would benefit immensely from the
ability to use wildcards, for instance.

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

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2005 18:13:01 -0500

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
 >> held by a node associated with the grantor. The latter require much
 >> more structure.
 >>

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.

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

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