Subject: [Sipping] Consent framework comments

From: [email-masked]
Date: Sun, 6 Nov 2005 17:27:23 +0200

Hi,

I read through the latest version of the Consent Framework draft and have a couple of comments.

In general I think this has moved to good and useful direction. I think that it is a good model to ask for consent when the translation is created, not just when someone tries to use it, as was in some older version. The proactive model should work quite well with services such as delivery lists. 

The draft now talks also about URI list services where the translation is created ad hoc, i.e. by carrying the list within the request body. Some important services, such as ad hoc conferencing and one-to-many messaging work in this way. I think it would be essential to make it possible to have preconfigured consent also for these type of services. For instance people should be able to setup consent for ME to invite them to ad hoc conferences. The problem is that while I would probably always create the ad hoc conference via the same 'factory URI', the actual conference URI (and thus the translation) would always be different, since the conference names are not constant. So, would it be possible to have consent policies like this:
- Any translation created by User X, using factory URI Y; or even
- Any translation created by User X in domain Y

I'm not sure if I was able to explain this properly, but the point is that it should be possible to express things quite flexibly about the translation and its scope. Obviously each user should be by default only able to set rules about translations where something is translated to their URI. Perhaps even things like SAML should be investigated for giving permissions.

About security considerations: I think that the main security consideration is that the framework relies that the actual translating elements (conf servers, URI list servers, ...), with whom the user has no relationship, still honor the consent setup by the user. I mean, what if there is a server in the Internet who does not care about the consent but just sends out INVITEs. This is pretty easy to handle intra-domain or wihtin a small federation, but how about Internet-wide. Should this kind of things be brought up in the VOIPEER context, i.e. what can be done about domains that do not enforce this type of policies? Can we at least require them to turn on the "evil bit" in their unsolicited requests? :-)

While this is not required for the draft, it would be good to list for SIPPING WG what kind of Standards Track RFCs should be generated to actually build a working consent system out of the framework, so that these pieces can be chartered and work started/distributed.

Regards,
	Markus  

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 07 Nov 2005 02:33:31 +0200

Hi Markus,

thanks for the comments. Answers inline:

 > So, would it be possible to have consent policies
> like this: - Any translation created by User X, using factory URI Y;
> or even - Any translation created by User X in domain Y

Yes, we need to discuss the format of the permission documents. We want 
something simple but with enough expresiveness to cover the main 
scenarios where consent is useful.

> Perhaps even things like SAML should be
> investigated for giving permissions.

In principle, we were thinking of a simple XML schema explicitly 
designed for consent, but it may be worthwhile exploring other 
alternatives as well, as you suggest.

The initial proposal was something like this:

    <target>
       <identity>
              <id>[email-masked]</id>
       </identity>
     </target>
     <sender>
       <identity>
         <any-identity/>
       </identity>
     </sender>
     <recipient>
       <identity>
         <id>[email-masked]</id>
       </identity>
     </recipient>
     <operations>
         <any-method/>
     </operations>

> what can be done about domains that do not
> enforce this type of policies?

I think this is indeed an interesting discussion to have... not so 
relevant to this draft at this point, though.

> While this is not required for the draft, it would be good to list
> for SIPPING WG what kind of Standards Track RFCs should be generated
> to actually build a working consent system out of the framework, so
> that these pieces can be chartered and work started/distributed.

Yes, we will coordinate these efforts with the SIP/SIPPING chairs and 
the AD.

Thanks,

Gonzalo