Subject: Re: [Sipping] Consent Framework Issue

From: "Andrew Allen" <[email-masked]>
Date: Mon, 17 Jul 2006 17:42:08 -0400

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.

--------------------------
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: Sipping <[email-masked]>
Sent: Mon Jul 17 16:33:11 2006
Subject: Re: [Sipping] Consent Framework Issue

On Jul 13, 2006, at 6:31 PM, Andrew Allen wrote:

> It seems to me that we need some way of ensuring that permissions  
> are somehow automatically transferable or re-creatable and also  
> that some trait or signature is used to identify that  
> [email-masked] is the same person as [email-masked]. It seems  
> to me that the Permission Server in the domains of the permission  
> grantor may need to store the permissions granted and be able to  
> automatically re-grant permissions based on the trait or signature  
> of an already allowed user when that user re-requests permissions  
> after changing domains – this would mean the Publish of the  
> granting of permissions would need to go back to the Relay via the  
> Permissions Server and the Permission Server would also maintain a  
> permission list of who their user had granted permission to.

You've posited a requirement that makes the problem isomorphic to the  
general identity problem, which puts it into the class of "currently  
unsolved and believed by many to be not solvable in the general case".

The problem is the "some trait or signature is used to identify that  
[email-masked] is the same person as [email-masked]" part. In  
the absence of a PKI or some other authentication anchor that is  
external to both biloxi and columbia, there's no known way to make  
this work.

Sure, we could have one PGP key for Alice and make both   
Alice@columbia-net and [email-masked] subkeys, but then we're back  
to the PGP-trusted-introducer problem, which (while mathematically  
tractable) hasn't seemed to catch on for people without nerd-genes.

--
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: Dean Willis <[email-masked]>
Date: Mon, 17 Jul 2006 17:45:06 -0500

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