Re: [mmox] OGP scalability concerns
Morgaine <morgaine.dinova@googlemail.com> Thu, 02 April 2009 10:32 UTC
Return-Path: <morgaine.dinova@googlemail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DEF3A6A5A for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 03:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxmcyAvwgzeb for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 03:32:03 -0700 (PDT)
Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 194B23A6847 for <mmox@ietf.org>; Thu, 2 Apr 2009 03:32:02 -0700 (PDT)
Received: by ewy9 with SMTP id 9so465615ewy.37 for <mmox@ietf.org>; Thu, 02 Apr 2009 03:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=70Oso9H+BIM6i6uL1AHgJrUyDmb205EdFwH9GYXc4PU=; b=txi8QbW4vnjy/p2FFwv2rubM9OqOwAU4ia0fKwsiCbFd6KJF6eYXKAI9q/YYuykDsE YnaYLQkO5LZt5Y85YnnZ6LP1ErAPuj/tinlaMoqdLc+6ByyS+p5bDz1N5BzjE6Ad9eIg UFhc9fuBsWmrKUFVWXYa+GDOP4ZCFfY4P4pKg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g+D/mgwxHlpoS/u3F97VYpqtC1oTNl9ynC20KMjZkhaKz5AJkzj3tPdlV1PNxbuBB1 GaKUv28qQDGkCYINkdJPJbmEx62CDYPXWfT43A06DjcOh0M5Oc2WBYruT1f98dZlVAyZ E0LR0GSFs6jsjVqJ4zqH9nBlqQuQp4GOnL2mA=
MIME-Version: 1.0
Received: by 10.216.10.210 with SMTP id 60mr2961296wev.81.1238668383241; Thu, 02 Apr 2009 03:33:03 -0700 (PDT)
In-Reply-To: <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com>
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com>
Date: Thu, 02 Apr 2009 11:33:03 +0100
Message-ID: <e0b04bba0904020333g1dab89b3g818e316f42a045@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
Content-Type: multipart/alternative; boundary="0016364d31f9fa468e04668ff4fc"
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] OGP scalability concerns
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2009 10:32:05 -0000
On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > John quoted<http://www.ietf.org/mail-archive/web/mmox/current/msg01211.html>>>> There will be millions of worlds in an Internet-scale metaverse, which >>> makes the concept of interop through trust agreements far too narrow. Trust >>> loses its meaning entirely when scaled to millions, becoming mere paperwork >>> or "security theater". >>> >> > +1. what's your suggestion? > > Jason's suggestion<http://www.ietf.org/mail-archive/web/mmox/current/msg01305.html>was accurate I believe, namely that centralized control of identity, trust and authentication is neither appropriate nor accepted on an Internet scale. To that I'll add another suggestion, based on my experience in the defense industry. Trust agreements *between* organizations are only useful in the context of transactions *at the level of* organizations, but are very inappropriate for dealing with transactions at other (lower or higher) levels: a single credential cannot carry an appropriate semantic for dealing with multiple levels of trust, secrecy, or security --- that's why single level credentials are never used in defense organizations. In our area, VWs perform transactions over a huge range of objects that have highly diverse sensitivities, ranging from no sensitivity at all up to (presumably) the highest levels of sensitivity demanded by business, finance and government. To try to encapsulate this in a single trust agreement between interoperating worlds just doesn't make sense. Different levels of trust actually cost different amounts of money to implement if they are to be meaningful, so you cannot have a blanket trust agreement that operates at all sensitivity levels unless you place a prohibitively high bar on entry. And if you don't mandate this high bar, then the whole agreement becomes "best effort only" and so you end up with the "security theater <http://en.wikipedia.org/wiki/Security_theater>" that I mentioned in John's quote in the context of Internet-size scaling. In view of the above two problems with trust agreements and also Jason's point, I believe that trust agreements don't actually have a useful role to play in VWs at all. Instead, I suggest that the machinery that was going to underpin trust agreements be used only for endpoint identification in the usual way, with no trust implied. It then becomes a *local policy decision*which data to release to the peer, and that policy decision will need to be made on the basis of concrete realities rather than based on the wishful thinking of a trust agreement. While we are not concerned with local policy decisions in MMOX, I think it's fair to suggest that most such decisions should err on the side of caution. The above picture would not be complete without offering a solution for those who *do* require sensitive data to be made available to parties in remote worlds, as will be common in business. Because trust between worlds is largely meaningless yet secure object transfer is still needed, I suggest that one of the many well-designed cryptographic technologies be used to deliver individually encrypted items to their intended parties directly. Whether or not a MMOX protocol should assist in the transport of such opaque items between worlds is an interesting topic for discussion. This is probably appropriate material for the same design team that will deal with VW privacy and end-to-end encrypted communications to consider. (PS. For the benefit of those who do not work in this area, please note that what's become known as "DRM" is not correct usage of cryptography and should not be used where real security is required.) Morgaine. On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: > > A few days ago I posted an e-mail highlighting my concerns with the >> architecture of OGP. I'm not sure if there was an implicit agreement from >> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a >> new thread because I want to make sure I have a proper understanding of the >> architecture. >> >> >> * Indirectly, it highlights that the Agent Domain model does not >>> have a solution to the problem of accessing worlds with which there is >>> no trust agreement. People will want to enter arbitrary worlds, and >>> therefore that restriction is inadequate. >>> >> > i would guess the solution would be to have a promiscuous agent domain that > has a "i will trust all worlds" settings. i think this is a limitation of > the implementation, not the architecture. > > * There will be millions of worlds in an Internet-scale metaverse, >>> which makes the concept of interop through trust agreements far too >>> narrow. Trust loses its meaning entirely when scaled to millions, >>> becoming mere paperwork or "security theater". >>> >> > +1. what's your suggestion? > > > >> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps >> (whitelists) work great when IBM wants to define policy to connect to the >> Linden Lab grid, but has no meaning and no hope of scaling when you talk >> about defining trust for millions of simulation grids and millions (or at >> least thousands) of identity providers. This is the primary reason that >> Intel and many members of the OpenSimulator/OpenMetaverse community have not >> considered OGP as a strong proposal for virtual world interoperability. If >> this understanding is not accurate, it would be helpful if an OGP author >> could step in and clear up the confusion. >> >> John >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox >
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Lawson English
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jason Giglio
- Re: [mmox] OGP scalability concerns Rob Lanphier
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz