Subject: Re: [Sipping] Consent Framework Issue

From: "Andrew Allen" <[email-masked]>
Date: Mon, 17 Jul 2006 21:51:00 -0400

If identity is the key then it is consent that creates the deadbolts for the lock that requires me to keep the same key to prevent me being locked out from service - that is the really evil thing.

Simply having to change your telephone number was a major bar in the past to people switching telephone service - hence number portability regulations. Now with consent we create a situation where we bar outbound service and create a major effort for a user to tackle to get service back if they ever dare to switch their service provider.

I am not in principle hostile to consent but right now I fear we are creating a mantrap for user service portability with this.

--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: Dean Willis <[email-masked]>
To: Andrew Allen
Cc: [email-masked] <[email-masked]>
Sent: Mon Jul 17 18:45:06 2006
Subject: Re: [Sipping] Consent Framework Issue

On Jul 17, 2006, at 4:42 PM, Andrew Allen wrote:

>
> I welcome the comments on my suggested solution and agree that  
> solving this problem is non-trivial but does anyone contest the  
> description of the problem?
>
> In my view creating a situation which will effectively lock people  
> into a single service provider is "evil" and is a problem that to  
> me definitely far outways the benefit of the solution to the  
> problem that consent attempts to solve.

You are rather permanently "anchored" to your identity anchor. This  
is something of a tautology.

The "lock in" comes from having the service provider serve as an  
identity anchor. If you use something else as an identity anchor, you  
don't have this problem. Don't want to be locked to a service  
provider? Use something else as the identity anchor for your consent  
relationships.

Of course, most service providers will accept nothing else as an  
identity anchor, which is what makes them "evil".

--
Dean

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
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: Tue, 18 Jul 2006 17:08:57 +0300

Hi Andrew,

> If identity is the key then it is consent that creates the deadbolts 
> for the lock that requires me to keep the same key to prevent me 
> being locked out from service - that is the really evil thing.

not at all. If I have your SIP URI in my UA's white list and you change
your SIP URI, you will have to inform me so that I add you to my white
list again... and this happens without using consent.

What you are looking for, as Dean suggested, is an entity that certifies
that your new SIP URI belongs to the same person as your old URI. And
that has nothing to do with consent either.

In the presence of such an entity (e.g., a CA in a PKI), the permissions 
could be transferred between trusted relays.

Cheers,

Gonzalo