Subject: [ogpx] Protocol for permitting policy decisions

From: Magnus Zeisig <[email-masked]>
Date: Mon, 5 Oct 2009 10:55:12 +0200

If I register with an agent domain, or authentication service, whichever should be the proper name for it, I will most probably hand them some pieces of information about myself that I don't want disseminated to anyone. Therefore, I think the protocol for granting access to regions and other services should not include such information explicitly, but rather let the agent domain/authentication service just answer questions from the other domain/service if the parameters are within acceptable range.

Instead of the revealing (meta-handshake):

Agent domain:
request access for
user: [email-masked]
age: 18
gender: male
sexuality: bi
country: pt
languages: pt, es, en, de
length: 1.82
weight: 122
color of socks: blue

Region domain:
access granted for
user: [email-masked]

The handshake should instead be:

Agent domain:
request access for
user: [email-masked]

Region domain:
require parameter values
languages: es AND (de OR hb OR ru)
length: [1.21-2.42]
color of socks: pink OR blue OR black
hairdo: shaved OR ponytail

Agent domain:
required parameter values
languages: yes
length: yes
color of socks: yes
hairdo: n/a

After which the region domain might decide that the missing hairdo parameter is not crucial and grant access, or refuse access because of it:

Region domain:
access denied for
user: [email-masked]

This has the benefit of permitting service providers to require what user parameters they think are important, be it age or color of socks, but the disadvantage of some extra overhead and the risk of balkanization because of requirements of "odd" parameters only supported by few services. The latter, however, I believe will become self-eliminating, because such services will probably not find many users. Either way, I don't think the protocol in itself should require any particular parameters, like age or color of socks, just provide the means to communicate any parameters, and perhaps suggest a list of possible, but not required, parameters and formats for values, like options, ranges and enumerations. The same kind of handshake could also be used when requesting access to asset services and the like, even if parameters like "object types" and "ip agreements" may be more important than "color of socks" there.

Best regards,

Magnus

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Mon, 5 Oct 2009 14:48:47 +0000

I think Magnus’ message is a good synopsis of the requirements, IMO.  I see a need to negotiate *both* capabilities and constraints in the protocol where both should be ideally attributes in an extensible list (that is the list isn’t hard coded in the protocol definition).  So, IMO, authentication isn’t enough.  Beyond authenticating there’s an exchange around caps and constraints that needs to take place.  I’d use that mechanism to handle “Adult only” regions, membership in a group where the group is defined outside the scope of the protocol, etc.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Zeisig
Sent: Monday, October 05, 2009 3:55 AM
To: [email-masked]
Subject: [ogpx] Protocol for permitting policy decisions

Agent domain:
request access for

Region domain:
access granted for

Agent domain:
request access for

Region domain:
require parameter values

Agent domain:

Region domain:
access denied for

Best regards,

Magnus

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 5 Oct 2009 09:32:34 -0700

again, this is a matter of policy, not a matter of protocol.

let me give you a counter example. some trusted organization, maybe
the new zealand sea scouts, decides it wants a virtual social space to
teach seamanship, knot tying and whatever else scouts are taught these
days.

the sea scouts organization is not really known for it's ability to
maintain a reasonably large networking and system infrastructure, so
instead of building the service themselves, they outsource.

at this point, there are a couple of options open to them. they can
give their entire user database to a third party and hope for the
best. or they can give portions of their user database (name, email
address, adult / minor boolean.) or they could put a VWRAP
authentication service that they maintain in front of their user
database. each are valid options.

one would hope that in the first two options, they worked out with the
third party some pretty hard-core data retention and privacy policies.

so what if they did the third option? what would the protocol have to
do? the sea scout's agent domain would only allow agents to enter a
private virtual world. the sea scouts would negotiate with their
region domain provider to ensure that adult content was not allowed in
the regions accessible by the sea scout agent domain. moreover, the
region domain provider could ensure that ONLY agents with accounts
from the sea scouts would get access to the sea scouts virtual spaces.

so the answer to the question of "what does the protocol have to do?"
is that it only has to convey information about the identity of the
agent domain to the region provider. it also has to have a mechanism
for the agent domain to identify the region.

but the protocol itself does not impose restrictions as to the
identity of either party. that is a policy issue.

in other words, if you don't want to use an agent domain  / region
domain pair that provides information about you to a trusted third
party, don't give that information the the agent domain in the first
place. or double check that the agent domain's privacy policy requires
third parties to which it reveals information to  treat that
information with due care.

that being said, some people's paranoia level is higher than others,
so maybe we could have multiple techniques defined for sharing
sensitive information, none of which are mandatory.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software)
<[email-masked]> wrote:
> I think Magnus’ message is a good synopsis of the requirements, IMO.  I see
> a need to negotiate *both* capabilities and constraints in the protocol
> where both should be ideally attributes in an extensible list (that is the
> list isn’t hard coded in the protocol definition).  So, IMO, authentication
> isn’t enough.  Beyond authenticating there’s an exchange around caps and
> constraints that needs to take place.  I’d use that mechanism to handle
> “Adult only” regions, membership in a group where the group is defined
> outside the scope of the protocol, etc.
>
>
>
> Mike
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hash: SHA256
>
>
>
> If I register with an agent domain, or authentication service, whichever
> should be the proper name for it, I will most probably hand them some pieces
> of information about myself that I don't want disseminated to anyone.
> Therefore, I think the protocol for granting access to regions and other
> services should not include such information explicitly, but rather let the
> agent domain/authentication service just answer questions from the other
> domain/service if the parameters are within acceptable range.
>
>
>
> After which the region domain might decide that the missing hairdo parameter
> is not crucial and grant access, or refuse access because of it:
>
>
>
> Region domain:
>
> access denied for
>
> This has the benefit of permitting service providers to require what user
> parameters they think are important, be it age or color of socks, but the
> disadvantage of some extra overhead and the risk of balkanization because of
> requirements of "odd" parameters only supported by few services. The latter,
> however, I believe will become self-eliminating, because such services will
> probably not find many users. Either way, I don't think the protocol in
> itself should require any particular parameters, like age or color of socks,
> just provide the means to communicate any parameters, and perhaps suggest a
> list of possible, but not required, parameters and formats for values, like
> options, ranges and enumerations. The same kind of handshake could also be
> used when requesting access to asset services and the like, even if
> parameters like "object types" and "ip agreements" may be more important
> than "color of socks" there.
>
>
>
> Best regards,
>
>
>
> Magnus
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: 9.8.3 (Build 4028)
>
> Charset: utf-8
>
>
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
>
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
>
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
>
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
>
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
>
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg==
>
> =H2Fj
>
> -----END PGP SIGNATURE-----
>
>
>
>
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Mon, 5 Oct 2009 17:12:03 +0000

I think I buy it in the case you put forward.  That is if you simplify the problem so that AD itself specifies the constraint (the AD in your example only carries accounts from the sea scouts).  But what if I'm running multiple regions with different policies all served by a single AD? Are you suggesting that each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised...  If I'm running multiple regions, some of which are "Adult" and some are not, does treating constraints as outside the protocol require each RD to do the age verification (I could make a case the answer is yes since "Adultness" might differ depending on who/where I am).  And if so how do they do that without getting "sensitive information" that is probably best owned by the AD.  Is it reasonable perhaps for a RD to delegate that to the AD and provide a mechanism to negotiate the details on connect so I can centralize such decisions in a single place?

Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:[email-masked]] 
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; [email-masked]
Subject: Re: [ogpx] Protocol for permitting policy decisions

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software)
<[email-masked]> wrote:
> I think Magnus' message is a good synopsis of the requirements, IMO.  I see
> list isn't hard coded in the protocol definition).  So, IMO, authentication
> isn't enough.  Beyond authenticating there's an exchange around caps and
> constraints that needs to take place.  I'd use that mechanism to handle
> "Adult only" regions, membership in a group where the group is defined

---

From: Morgaine <[email-masked]>
Date: Mon, 5 Oct 2009 18:54:18 +0100

You're opening up a can of worms of biblical proportions here, Mike.

What in hell's teeth is an "Adult only region"?  Who gets to define it?
Under what rules?  In what legal jurisdiction?  And those are just the
simplest questions, pertaining to worlds that are merely reflections of the
physical world.  What about virtual worlds that intentionally maintain
separation from RL, bearing in mind the recent augmentism versus
immersionism thread?  Each immersionist's world is separate from all others,
and your value judgements from elsewhere are not importable to those
worlds.  What about fantasy worlds?  Is a naked orc "Adult content"?  How do
you judge "Adult only" in a virtual world set in our distant future?  How do
you judge "Adult only" in a virtual world of aliens?  What about in a
virtual world of classic art recreations in all their naked and educational
glory?  And there are probably another 500 questions like this one.

It's not just a can of worms.  It's totally unworkable, nothing more than
theater, and verging on farce or comedy.  I bet that some readers here who
are not exposed to recent events in Second Life may be wondering why this
topic has even appeared in these discussions.

One particular world provider has implemented a ratings system within its
own walled garden, and this has been confused with the requirements of
interop outside of a walled garden.  Such ratings systems may be workable
within a single managed domain in which the provider has total control over
region spaces and asset services and can sanction individuals who break the
rules, but it does not extrapolate to multiple worlds with separate Terms
and Conditions, different jurisdictions, or varying cultures, even when
they're all mirrors of the physical world.  Even less can it work or apply
in the general case of immersionist virtual worlds.

This is extremely poorly considered, on numerous fronts.

Authentication is more than enough for coarsely segregating highly
restricted enclaves from the general mass of virtual worlds.  Going beyond
that is simply unworkable across multiple separate virtual virtual worlds,
when you look at the implications.

Morgaine.

==================================

On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

>  I think Magnus’ message is a good synopsis of the requirements, IMO.  I
> see a need to negotiate **both** capabilities and constraints in the
> protocol where both should be ideally attributes in an extensible list (that
> is the list isn’t hard coded in the protocol definition).  So, IMO,
> authentication isn’t enough.  Beyond authenticating there’s an exchange
> around caps and constraints that needs to take place.  I’d use that
> mechanism to handle “Adult only” regions, membership in a group where the
> group is defined outside the scope of the protocol, etc.
>
>
>
> Mike
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Magnus Zeisig
> *Sent:* Monday, October 05, 2009 3:55 AM
> *To:* [email-masked]
> *Subject:* [ogpx] Protocol for permitting policy decisions
>
>
>
> After which the region domain might decide that the missing hairdo
> parameter is not crucial and grant access, or refuse access because of it:
>
>
>
> Region domain:
>
> access denied for
>

---

From: Morgaine <[email-masked]>
Date: Mon, 5 Oct 2009 19:06:36 +0100

That's an issue specific to the particular policies of Second Life, and like
all matters of policy, it doesn't involve us here.

In fact, that's exactly what Meadhbh wrote in the email to which you
responded, and her words are spot on.

Morgaine.

=======================================

On Mon, Oct 5, 2009 at 6:12 PM, Dickson, Mike (ISS Software) <
[email-masked]> wrote:

> I think I buy it in the case you put forward.  That is if you simplify the
> problem so that AD itself specifies the constraint (the AD in your example
> only carries accounts from the sea scouts).  But what if I'm running
> multiple regions with different policies all served by a single AD? Are you
> suggesting that each region needs to handle the policy for its own?
>
> Picking on what is probably a corner case but one that's been raised...  If
> I'm running multiple regions, some of which are "Adult" and some are not,
> does treating constraints as outside the protocol require each RD to do the
> age verification (I could make a case the answer is yes since "Adultness"
> might differ depending on who/where I am).  And if so how do they do that
> without getting "sensitive information" that is probably best owned by the
> AD.  Is it reasonable perhaps for a RD to delegate that to the AD and
> provide a mechanism to negotiate the details on connect so I can centralize
> such decisions in a single place?
>
> Mike
>
> parameter

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Mon, 5 Oct 2009 18:07:40 +0000

I'm going to drop this since I'm a poor choice to defend the case.  In principle I agree with Morgaine and the LL folks don't seem to see a need for this sort of handshake.  I do personally see cases where the AD and RD may want to share attribute information on a connect but it could be done out of band and so isn't really required to make the VWRAP bits work.  And in answer to the question Morgaine raised... i.e.  who gets define what adult only is, it's the region IMO hence the reason (if I understood)  Meadbah argued it's a matter of policy and not protocol.

Apologies if I tested anyone's patience.  I'm still working through these cases in my own head.

Mike

From: Morgaine [mailto:[email-masked]]
Sent: Monday, October 05, 2009 12:54 PM
To: Dickson, Mike (ISS Software)
Cc: [email-masked]
Subject: Re: [ogpx] Protocol for permitting policy decisions

What in hell's teeth is an "Adult only region"?  Who gets to define it?  Under what rules?  In what legal jurisdiction?  And those are just the simplest questions, pertaining to worlds that are merely reflections of the physical world.  What about virtual worlds that intentionally maintain separation from RL, bearing in mind the recent augmentism versus immersionism thread?  Each immersionist's world is separate from all others, and your value judgements from elsewhere are not importable to those worlds.  What about fantasy worlds?  Is a naked orc "Adult content"?  How do you judge "Adult only" in a virtual world set in our distant future?  How do you judge "Adult only" in a virtual world of aliens?  What about in a virtual world of classic art recreations in all their naked and educational glory?  And there are probably another 500 questions like this one.

It's not just a can of worms.  It's totally unworkable, nothing more than theater, and verging on farce or comedy.  I bet that some readers here who are not exposed to recent events in Second Life may be wondering why this topic has even appeared in these discussions.

One particular world provider has implemented a ratings system within its own walled garden, and this has been confused with the requirements of interop outside of a walled garden.  Such ratings systems may be workable within a single managed domain in which the provider has total control over region spaces and asset services and can sanction individuals who break the rules, but it does not extrapolate to multiple worlds with separate Terms and Conditions, different jurisdictions, or varying cultures, even when they're all mirrors of the physical world.  Even less can it work or apply in the general case of immersionist virtual worlds.

Authentication is more than enough for coarsely segregating highly restricted enclaves from the general mass of virtual worlds.  Going beyond that is simply unworkable across multiple separate virtual virtual worlds, when you look at the implications.

Morgaine.

==================================
On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) <[email-masked]<mailto:[email-masked]>> wrote:

I think Magnus' message is a good synopsis of the requirements, IMO.  I see a need to negotiate *both* capabilities and constraints in the protocol where both should be ideally attributes in an extensible list (that is the list isn't hard coded in the protocol definition).  So, IMO, authentication isn't enough.  Beyond authenticating there's an exchange around caps and constraints that needs to take place.  I'd use that mechanism to handle "Adult only" regions, membership in a group where the group is defined outside the scope of the protocol, etc.

Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Magnus Zeisig
Sent: Monday, October 05, 2009 3:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [ogpx] Protocol for permitting policy decisions

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Agent domain:

request access for

user: [email-masked]<mailto:[email-masked]>

age: 18

gender: male

sexuality: bi

country: pt

length: 1.82

weight: 122

color of socks: blue

Region domain:

access granted for

user: [email-masked]<mailto:[email-masked]>

Agent domain:

request access for

user: [email-masked]<mailto:[email-masked]>

Region domain:

require parameter values

length: [1.21-2.42]

Agent domain:

languages: yes

length: yes

color of socks: yes

hairdo: n/a

Region domain:

access denied for

user: [email-masked]<mailto:[email-masked]>

Best regards,

Magnus

_______________________________________________
ogpx mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ogpx

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 11:59:19 -0700

On Mon, Oct 5, 2009 at 10:54 AM, Morgaine
<[email-masked]> wrote:
> What in hell's teeth is an "Adult only region"?

an adult only region is a region which contains content that may be
considered adult in nature. but again, this is a matter of policy, not
a matter of protocol. the protocol should be able to carry tags
protocol consumers can use to identify regions as having an "adult
nature."

> Who gets to define it?

probably a lawyer familiar with the case history of accessing adult
content on the internet. but again, this is a matter of policy, not a
matter of protocol. the protocol should be able to carry tags protocol
consumers can use to identify regions as having an "adult nature."

> Under what rules?

probably under rules radically similar to the ones currently used to
define operator's policies. VWRAP is a protocol, not a product. the
creation of a new protocol to carry information about virtual places
does not change international legal frameworks. but again, this is a
matter of policy, not a matter of protocol. the protocol should be
able to carry tags protocol consumers can use to identify regions as
having an "adult nature."

> In what legal jurisdiction?

probably under jurisdictions radically similar to the ones currently
used to define operator's policies. but again, this is a matter of
policy, not a matter of protocol. the protocol should be able to carry
tags protocol consumers can use to identify regions as having an
"adult nature."

> And those are just the
> immersionism thread?

in many jurisdictions, the intent of the service operator is not
material to cases related to the distribution of adult content. but
again, this is a matter of policy, not a matter of protocol. the
protocol should be able to carry tags protocol consumers can use to
identify regions as having an "adult nature."

> Each immersionist's world is separate from all others,
> worlds.  What about fantasy worlds?

in many jurisdictions, the intent of the service operator is not
material to cases related to the distribution of adult content. but
again, this is a matter of policy, not a matter of protocol. the
protocol should be able to carry tags protocol consumers can use to
identify regions as having an "adult nature."

> Is a naked orc "Adult content"?

ugh. unfortunately, we won't know that until someone raises a legal
challenge which is either successfully defended against or
successfully prosecuted. some jurisdictions may simply restrict access
to content they do not like. but again, this is a matter of policy,
not a matter of protocol. the protocol should be able to carry tags
protocol consumers can use to identify regions as having an "adult
nature."

> How do you judge "Adult only" in a virtual world set in our distant future?

you don't. because we're talking about a protocol that can be used in
the near future. the distant future can take care of itself. but
again, this is a matter of policy, not a matter of protocol. the
protocol should be able to carry tags protocol consumers can use to
identify regions as having an "adult nature."

> How do you judge "Adult only" in a virtual world of aliens?

ugh. unfortunately, we won't know that until someone raises a legal
challenge which is either successfully defended against or
successfully prosecuted. some jurisdictions may simply restrict access
to content they do not like. but again, this is a matter of policy,
not a matter of protocol. the protocol should be able to carry tags
protocol consumers can use to identify regions as having an "adult
nature."

>What about in a  virtual world of classic art recreations in all their naked and educational
> glory?

ugh. unfortunately, we won't know that until someone raises a legal
challenge which is either successfully defended against or
successfully prosecuted. some jurisdictions may simply restrict access
to content they do not like. but again, this is a matter of policy,
not a matter of protocol. the protocol should be able to carry tags
protocol consumers can use to identify regions as having an "adult
nature."

> And there are probably another 500 questions like this one.

it's okay. bits are cheap.

> topic has even appeared in these discussions.

 the fact of the matter is that laws and regulations covering access
of "adult" material is a patchwork and is frequently difficult to
navigate. saying "it's difficult" and ignoring it (like you
recommended we do with security in the MMOX discussions) is not an
option. there are many people who want to use this protocol that want
a tool to help limit their exposure to legal liability.

> in the general case of immersionist virtual worlds.

very well then. how do you recommend virtual world operators shield
themselves from legal liability?

> On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software)
>> see a need to negotiate *both* capabilities and constraints in the protocol

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 12:19:40 -0700

mike, don't let morgaine shout you down.

i'm interested in having a serious conversation about the subject.

a number of us will need to develop a "regime" regions may use to flag
the presence of adult content. and the protocol flows should be able
to carry this (and related) information so either the AD or the RD can
make whatever policy decisions they think they need to make.

that being said... morgaine's comments do show the difficulty (or even
impossibility) of trying to create an internet-wide standard for adult
content. but, if we don't add this to the standard, i think a lot of
people will be implementing their own, incompatible standard. (i mean
a standard for carrying meta data about the content of a region.)

second life currently has three levels of maturity (four if you count
the teen grid.) i cannot imagine we would ditch that for the privilege
of using a new standard. i would simply recommend that when we get
around to defining the information about a region communicated to an
agent domain, we include the provision for the communication of
meta-data about the region and leave it at that. we could then leave
it as a matter of policy for agent domains and region domains to
define the semantics of values defined for a "maturity" key.

keep in mind that this protocol is intended to be flexible. we don't
have to define the meaning of region labels in the protocol. in fact,
we don't have to define the "maturity" key at all. all we have to do
is say "this is where you put the meta-data."

if we wanted, we _could_ list a maturity key in the region descriptor.
if we don't do it here, it's not the end of the world. people will
define their own schemes. (for instance, i can't imagine second life
would be deployed without such a feature.)

or, we could create one and just tell people who don't care about
enforcing these rules to simply ignore them. at the end of the day,
you can't detect "adult content" in an automated fashion, so the
"adult content" tag is purely discretionary. the protocol will not
break if you fail to honor the maturity tag.

i suspect that if we defined a maturity scheme as part of the
protocol, it would wind up being something like HTTP authentication. a
system that is widely used, but due to it's weaknesses is frequently
augmented by other tools (like TLS) or completely replaced (like
logging in via a form, then having the server set an access token
cookie.) but just because HTTP auth has it's problems, doesn't mean
they removed headers from HTTP messages.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 11:07 AM, Dickson, Mike (ISS Software)
<[email-masked]> wrote:
> I’m going to drop this since I’m a poor choice to defend the case.  In
> principle I agree with Morgaine and the LL folks don’t seem to see a need
> for this sort of handshake.  I do personally see cases where the AD and RD
> may want to share attribute information on a connect but it could be done
> out of band and so isn’t really required to make the VWRAP bits work.  And
> in answer to the question Morgaine raised… i.e.  who gets define what adult
> only is, it’s the region IMO hence the reason (if I understood)  Meadbah
> argued it’s a matter of policy and not protocol.
>
>
>
> Apologies if I tested anyone’s patience.  I’m still working through these
> cases in my own head.
>
>
>
> Mike
>
>
>

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 12:39:32 -0700

right. this is similar to what i was talking about in one of the
previously mentioned options. i mentioned that the region might need
to call back into the agent domain to get more information about a
particular agent. to me it looks like you're suggesting a two-message
handshake instead of the region turning around and querying the agent
domain.

lemme draw some diagrams:

"name" and "age" are bits of data that, like you might expect, are an
account identifier and the account holder's age. "rez cap" is the
capability used to establish the agent's presence in that region. "age
> X? cap" is a capability granted to the agent domain that's supposed
to be used by the agent domain only if the agent domain agrees that
the account holder is older than X.

option 1: information push

AD ------------ ( name, age ) ---------> RD
AD <------------- (rez cap) ------------ RD

option 2: RD queries the AD

AD --------------- (name) -------------> RD
AD <----- (is name older than X?) ------ RD
AD -------------- (yes/no) ------------> RD
AD <------------ (rez cap) ------------- RD

option 3: multi-message handshake

AD --------------- (name) -------------> RD
AD <-------- (X, age > X? cap) --------- RD

AD ------------------------------------> RD (age > X? cap)
AD <------------ (rez cap) ------------- RD

option 3 here is my attempt to model what magnus is talking about, but
with a RESTful capability system.

-cheers
-meadhbh

---

From: David W Levine <[email-masked]>
Date: Mon, 5 Oct 2009 16:20:28 -0400

So.. to sound like a broken record The policy decisions end up being 
applied to services. To an extent, this sort of implies that the 
enforcement point *has* to be the service, not the "domain" but.. one 
important point right behind this.
There is nothing which prevents a region from letting a front end service 
handle access to it. In particular, one very sane model for handling the 
cap grant to a large cluster of regions is to deploy that on a front end 
box, which handles
all of that separate from the region process, and hands out caps to the 
actual region. 

- David

"Dickson, Mike (ISS Software)" <[email-masked]> 
Sent by: [email-masked]
10/05/2009 01:12 PM

To
Meadhbh Siobhan <[email-masked]>
cc
"[email-masked]" <[email-masked]>, Magnus Zeisig <[email-masked]>
Subject
Re: [ogpx] Protocol for permitting policy decisions

I think I buy it in the case you put forward.  That is if you simplify the 
problem so that AD itself specifies the constraint (the AD in your example 
only carries accounts from the sea scouts).  But what if I'm running 
multiple regions with different policies all served by a single AD? Are 
you suggesting that each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised... If 
I'm running multiple regions, some of which are "Adult" and some are not, 
does treating constraints as outside the protocol require each RD to do 
the age verification (I could make a case the answer is yes since 
"Adultness" might differ depending on who/where I am).  And if so how do 
they do that without getting "sensitive information" that is probably best 
owned by the AD.  Is it reasonable perhaps for a RD to delegate that to 
the AD and provide a mechanism to negotiate the details on connect so I 
can centralize such decisions in a single place?

Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:[email-masked]] 
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; [email-masked]
Subject: Re: [ogpx] Protocol for permitting policy decisions

-cheers
-meadhbh

parameter

---

From: David W Levine <[email-masked]>
Date: Mon, 5 Oct 2009 16:33:38 -0400

I want to point out an important related concept for much of this 
discussion. 

If one's goal is to *know* that someone actually is following a policy one 
has, especially a policy with real world implications, the process has to 
ground out in provable statements. 
In fact, for cases where the policy covers legal liabilities, it has to 
ground out in legally meaningful stuff. I studied distributed systems, not 
law, so don't take any of this as a legal pronouncement,
but.. If I'm going to trust a third party Agent Domain to tell me 
something that has legal consequences, I'm probably going to want that 
statement tied down with a digital signature or similar
proof, that links to a real world document. 

So.. My personal suspicion is that what we'll see comes much closer to 
this:

"In order to have rights beyond "guest" on this region, you, or your agent 
domain, on your behalf, needs to have signed the TOS document. I will 
demand a digitally signed proof of this, as metadata when you 
request acess to my region."

- David
~ Zha

Infinity Linden <[email-masked]> 
Sent by: [email-masked]
10/05/2009 03:39 PM

To
Magnus Zeisig <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [ogpx] Protocol for permitting policy decisions

-cheers
-meadhbh

parameter

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 16:35:36 -0700

yes. we can have per-service policies. that's no big deal. but the software
implementing the service doesn't define policy, the people operating the
service do. the people (i.e. - the authority) is represented in the
specification as the "domain." so when we say "the domain sets policy" we
mean that when we have a bunch of machines, all of which are potentially
running different services, we mean that the owner of the machine running
the service sets the policy, not the developer(s) of the software or the
developer(s) of the protocol. that policy may be to defer policy setting to
a subordinate authority.
for example... on the second life grid, linden is likely to adopt a policy
that regions are squares 256m on a side, and that certain regions may only
be entered by administrators. on regions open to the general public, we may
(and do) subdivide land into parcels and allow our residents to limit who is
allowed to enter their parcels. (so... on mainland regions, we devolve
authority for setting the policy of who enters each region to the region
owners.) we also have a policy that even though you're not allowed to enter
a parcel, you can generally see what's in it.

a different developer may choose a different set of policies. that is, they
may decide not to subdivide regions into parcels, and may refuse to give
non-authorized clients information about items in virtual areas they don't
have access to.

another example might be a "private label agent domain." this would be an
operator or authority (or domain) that sets policies like... "we do not
support MD5 hash for password verification." but their business might be to
operate an agent domain on behalf of other organizations. one of these
clients may decide they have a policy that says "we will only authenticate
requests from IP addresses we believe are in a given locality." so in this
case, the private label agent domain operator devolves policy setting for
geo-location based authentication, but retains the right to refuse to use
the older MD5 based password authentication."

so... throughout the documentation... we use the term "domain" to mean
"a collection
of systems and networks over which control is exercised." the "authority" is
the entity (individual or group) that exercises the control. the
manifestation of the authority's control is (among other things) the ability
to set "policy." authority may be "devolved" to "subordinate authorities."
superior authority may decide which policy clauses to devolve and which to
retain. specific service interfaces deployed by a domain may implement
different policies.

ultimately it should not be the work of this group to determine policies for
domains, or even to provide an exhaustive list of policies. specific clauses
in a policy most likely arise from a specific implementation of the
protocol. it should not be the work of this group to bless any one
implementation and it's determination of how to represent policy. (i have
personally said many times that the effort of this group should not be to
bless Second Life(tm)'s legacy protocol and it's related policies. but this
does not mean that we should bless OpenSimulator.)

can we agree to this wording? can we move on?

On Mon, Oct 5, 2009 at 1:20 PM, David W Levine <[email-masked]> wrote:

> applied to services. To an extent, this sort of implies that the enforcement
> point *has* to be the service, not the "domain" but.. one important point
> right behind this.
> handle access to it. In particular, one very sane model for handling the cap
> grant to a large cluster of regions is to deploy that on a front end box,
> which handles
>  *"Dickson, Mike (ISS Software)" <[email-masked]>*
> Meadhbh Siobhan <[email-masked]>  cc
> From: Meadhbh Siobhan [mailto:[email-masked]<[email-masked]>]
>
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of
> > Magnus Zeisig

---

From: Infinity Linden <[email-masked]>
Date: Mon, 5 Oct 2009 16:38:43 -0700

On Mon, Oct 5, 2009 at 1:33 PM, David W Levine <[email-masked]> wrote:

> domain, on your behalf, needs to have signed the TOS document. I will demand
> a digitally signed proof of this, as metadata when you
i think i grok what you're trying to say here, but i would also add... "a
given agent domain MAY choose to deny you ANY service (including anonymous
or guest access) if you don't provide some form of authenticator and assert
that you have read and understand the domains terms of use."

-cheers
-meadhbh

---

From: Magnus Zeisig <[email-masked]>
Date: Tue, 6 Oct 2009 12:02:09 +0200

I try to follow the philosophical discussions on this list, but I must admit I'm probably a too much down to earth tech guy to fully appreciate them. Therefore, it's possible I miss some of the fine nuances or problems in them. My basic interest is trying to translate the problems I see into (meta)protocol. Exact nomenclature and syntax, e.g. "domain" or "service", "access" or "caps", I prefer leaving to those better called to define it. I hope this doesn't cause too much confusion.

My basic suggestion of a handshake protocol permitting policy decisions (http://www.ietf.org/mail-archive/web/ogpx/current/msg00475.html) could (strictly technically) handle the debated issues of authentication, "adult content" and TOSes:

Agent domain:
request access for

Region domain:
require parameter values for
user: [email-masked]
authentication: PASSPORT OR USSSN OR EUID OR JPVER
accept adult content: YES
accept nudity: YES
accept sexual acts: YES
accept profane language: YES
terms of service: ((FRLAWINFO2006:128 AND EULAWIP2008:2) OR USLAWTELECOM2005:1) AND (VWTOS1.2 OR MVTOS2.3 OR MYTOS1.0)
user signature: TOKEN

Agent domain:
required parameter values for
user: [email-masked]
authentication: yes
accept adult content: yes
accept nudity: yes
accept sexual acts: yes
accept profane language: no
terms of service: yes
user signature: 238158-2356257-238658-23596

Region domain:
access denied for
user: [email-masked]
(outside protocol: since not accepting profane language)

Using this method, one could decide to let the agent domain manage the acceptance of "adult content" entirely, by the region domain not asking for age but let the agent domain automatically set accept for e.g. "adult content", "nudity", "sexual acts" and "profane language" to NO for those underage and as options YES/NO for those of age. One could also either ask for acceptance of "adult content" in general or for more specific parameters often associated with "adult content", giving great flexibility in policy making. But once again, that is policy outside protocol level.

Best regards,

Magnus

- -----Ursprungligt meddelande-----
Från: Infinity Linden [mailto:[email-masked]]
Skickat: den 6 oktober 2009 01:39
Till: David W Levine
Kopia: Magnus Zeisig; [email-masked]; [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

        "In order to have rights beyond "guest" on this region, you, or your agent domain, on your behalf, needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you
        request acess to my region."

        - David
        ~ Zha

i think i grok what you're trying to say here, but i would also add... "a given agent domain MAY choose to deny you ANY service (including anonymous or guest access) if you don't provide some form of authenticator and assert that you have read and understand the domains terms of use."

- -cheers
- -meadhbh

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Oct 2009 13:19:19 +0200

On Mon, Oct 05, 2009 at 09:32:34AM -0700, Meadhbh Siobhan wrote:
> let me give you a counter example. [...snip...]

> identity of either party. that is a policy issue.

Correct me if I'm wrong, but you are saying that every AD needs
to add a configuration for each region that is serves to know
what to do when a given user wants to TP to that region?

And the protocol does not provide a way for the RD to change that
configuration.

That sounds like a can of worms in terms of administration horrors.
It's not flexible at all, it would make it very labour intensive
to add a new AD to some RD, or for an RD to switch to a different
AD. 'Trust' wouldn't be enough anymore.

Imho, we MUST PUT THE MEANS OF (RE)CONFIGURATION OF REGION DOMAIN
POLICIES IN THE HANDS OF THE REGION DOMAIN! Let them change it
daily, and immediately, if they wish.

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Oct 2009 13:35:47 +0200

On Mon, Oct 05, 2009 at 04:35:36PM -0700, Infinity Linden wrote:
> so... throughout the documentation... we use the term "domain" to mean "a 
> collection of systems and networks over which control is exercised." the
> "authority" is the entity (individual or group) that exercises the control. the
> manifestation of the authority's control is (among other things) the ability to
> set "policy." authority may be "devolved" to "subordinate authorities."
> domains, or even to provide an exhaustive list of policies. specific clauses in
> a policy most likely arise from a specific implementation of the protocol. it
> should not be the work of this group to bless any one implementation and it's
> determination of how to represent policy. (i have personally said many times
> that the effort of this group should not be to bless Second Life(tm)'s legacy
> protocol and it's related policies. but this does not mean that we should bless
> OpenSimulator.)

This makes sense.

> can we agree to this wording?

yes

> can we move on?

no, still need answers to other questions :p

---

From: David W Levine <[email-masked]>
Date: Tue, 6 Oct 2009 09:49:19 -0400

Well, I'd again (like the sadly broken record I'm becoming on this topic) 
say its a service or set of services which denies the access, but quite. A 
deployer is free to apply any policy they chose to a service request. If 
they only want people who have visited Candy Mountain, Surrendered a 
Kidney, and can prove it in the form of the ability to respond to provide 
a special token from the magical unicorn powered talisman they get from 
the Leoplueridon to access a given service, so be it. The protocol need 
merely allow them to insert:
<map>
<key>unicorn_talisman_token</key>
<string>shun the unbeliever</string>
</map> 

in an expected spot, and they can reject people who can't provide the 
correct response.

- David
~ Zha

10/05/2009 07:38 PM

To
David W Levine/Watson/IBM@IBMUS
cc
Magnus Zeisig <[email-masked]>, "[email-masked]" <[email-masked]>, 
[email-masked]
Subject
Re: [ogpx] Protocol for permitting policy decisions

- David 
~ Zha 

i think i grok what you're trying to say here, but i would also add... "a 
given agent domain MAY choose to deny you ANY service (including anonymous 
or guest access) if you don't provide some form of authenticator and 
assert that you have read and understand the domains terms of use."

-cheers
-meadhbh

---

From: Vaughn Deluca <[email-masked]>
Date: Tue, 6 Oct 2009 22:05:44 +0200

Maybe this will help also: Anything we have said so far on policy in this
discussion relates to protocol *options*  someone *might* use. None of this
will be REQUIRED. The protocol will function without using any of it.  So
really, as far as i can see we *can* move on.
--Vaughn

---

From: Carlo Wood <[email-masked]>
Date: Wed, 7 Oct 2009 11:24:52 +0200

It still matters whether or not it's possible to query the AD about
things the RD might want to deny someone access over or not (IP, email address,
age).

If that is not possible, than in PRACTISE I forsee that there will be
much less cooperation, and thus interop, between AD's and RD's of different
administrations.

For example, in order to be able to ban people by email address, each
RD might choose to run their own AD and not accept third party AD's.

Sending an email, requesting a ban by email address, won't work, of cours :/
Too slow, no response... certainly not if the RD is small and considered
insignificant and the AD has a monopoly and serves large grids.

Therefore I think the protocol must support real-time a few important
datas about users, so that the RD can make a decision, quickly and without
human intervention from the AD.

---

From: Vaughn Deluca <[email-masked]>
Date: Wed, 7 Oct 2009 20:12:19 +0200

Although I actually think enough has been said on policy,  I want to expand
my last message a bit to make it even more clear how i view this problem.

In wrote:
 "Anything we have said so far on policy in this discussion relates to
protocol *options*  someone *might* use. None of this will be REQUIRED. The
protocol will function without using any of it.  So really, as far as i can
see we *can* move on."

Here is a longer version of the same message:

We are talking policy, and by definition, everybody is free to ignore
policy, and live with the consequences.  If I run a some services in a RD,
its my choice what  policy i set to determine what is allowed in there. Yet,
a visiting agent is under *its*  ADs policy if I like that or not. Its the
agents choice to be in that AD.

If the policy of that AD is allowing, or even encouraging, the use of deadly
weapons,  while I like my regions to be free of violence. I can ignore the
policy of the agents AD. I am free to do so, and apply a policy of "ban on
the first sight of a gun", after all I run this service. Ignoring the policy
of the AD may carry the consequence of spoiling my relations with that AD,
since they strongly belief in the freedom to carry weapons, and this may
prompt them to prevent any TP to my RD. Yet that is about all thats in the
power of the AD, unless it has some legal hooks in my service via a real
world contract with me.

A more realistic example could be that it is the policy of the AD --or
rather  some associated asset service *winks to Zha* -- to only let go of
purple clothes under strict conditions. I have struck a deal with that
service, promising to follow the rules for purple cloths. Its my choice to
live by that promise, or -at my peril- ignore it. So to answer one of
Carlo's older questions, yes, from the perspective of the region service,
the Asset service policy *can* be forgotten and ignored,  but most likely I
will prefer not to do so, or I would not have made the deal in the first
place.

While all this is very interesting, its  *outside* of the scope of the
protocol.
Policy can be ignored, or followed, and its up to those setting the policies
to enforce them, by whatever means they have at their disposal, but it has
nothing to do with the protocol as such.

Infinity is eager to move on, and I fully agree with her. I suddenly
realised that the source of much of our problems might be that few people
have made it clear that *whatever* method  we pick to carry  policy related
information, the use of that information  will *always* be optional, and
never REQUIRED by protocol.

I do not think there is a single person on the list that will disagree with
this, and the chances of getting anything else than this past the IETF are
in my view remote. [I am new to protocol discussions, but there surly must
be precedents for this? We can't possibly be the first group to hit this
obstacle?].

We can spend a very long time talking about the way to code the policy
related information, and how explicit it is allowed to be; If it should be
only payload, or actual part of the control flow; If it may contain actual
values, or better only ranges. All of that is however somewhat moot as soon
as it is realised that its *optional* to provide and/or use this info.

There is not much chance we will gain full or even rough consensus on what
is appropriate to put in the meta-information, because it depends fully on
deeply personal value systems. One persons nightmare of a totalitarian state
is the next persons hope to be free from adult material or unrestrained
violence.

The crux is that we realise that the use of anything that will be in the
protocol relating to policy is optional. If I don't like that info to be
there, I don't supply it, and ignore it if I find it. Nothing will break in
protocol terms.

We could (and probably should) have some discussion how far we want to go in
facilitating certain use-cases by defining explicit fields to make interop
easy. Not many will defend a pre-defined field for real-life skin color to
allow other services more easy discrimination. But *even* if we had the (in
my eyes) bad taste to define such a field or tag to aid some (in my eyes)
unacceptable use-case, we are certainly NOT going to REQUIORE its use in the
protocol, nor saying it MAY NOT be carried ever, since however wrong we
think such a tag might be, it is a matter of policy, and as such outside the
scope of the protocol. If we decided in this group that such a tag should be
forbidden, and MUST NOT be carried we open the gates for demands that other
tags must also be forbidden. And conversely, if we REQUIRE the use of such a
tag, we can not prevent others in this discussion to REQUIRE other tags. And
everything will end in tears.

I think most (no, *all*) of what i just said  has been mentioned before on
the list in one form or another, and i really do not think there is much
more to add that is pertinent to the protocol. I hold  some (strong)
convictions how meta information should be carried, in particular relating
to privacy issues, but non of that is crucial, given that i am never forced
to give this information, nor prevented from using it if somebody is sending
it.
That said, if I as a user don't like the choices made by some service, i
SHOULD be able to pick another with in my view better options, or even run
one myself. So lets move on, and make that possible!

-Vaughn

---

From: Carlo Wood <[email-masked]>
Date: Wed, 7 Oct 2009 22:35:35 +0200

> AD <------------ (rez cap) ------------- RD

Note, again, the need for a flexible protocol negotiation:
we can't know, already, what all will be needed.

Nevertheless, the more flexibility the better imho.
I'd prefer to see this:

AD ------(name, <list with keywords>) -----------> RD
AD <-----(name, <list with keywords + ranges>) --- RD
AD ------(name, yes/no)--------------------------> RD
AD <-----(rez cap) ------------------------------- RD

Where VWRAP will not define what keywords are possible.

However, implementers might, for example, choose to use 'AGE' as keyword
with an integer range, leading to a msg exchange like

AD ------(name, (AGE)) -----------> RD
AD <-----(name, (AGE, 21)) -------- RD
AD ------(name, yes)--------------> RD
AD <-----(rez cap) ---------------- RD

or some might implement

AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), YES) ------------------ RD
AD ------(name, yes, yes)------------------------> RD
AD <-----(rez cap) ------------------------------- RD

For privacy reasons, I think it would suffice to
just send the AND of all 'yes's, thus:

AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), YES) ------------------ RD
AD ------(name, yes)-----------------------------> RD
AD <-----(rez cap) ------------------------------- RD

or,

AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), DONTCARE) ------------- RD
AD ------(name, yes)-----------------------------> RD
AD <-----(rez cap) ------------------------------- RD

Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us,
but we would define how to handle integer ranges, booleans,
don't cares, string literals, and perhaps regular expressions.

---

From: Carlo Wood <[email-masked]>
Date: Wed, 7 Oct 2009 22:49:17 +0200

I think this would require too much detail of 'filtering' parameters
to go into the actual protocol.

On Tue, Oct 06, 2009 at 12:02:09PM +0200, Magnus Zeisig wrote:
> I try to follow the philosophical discussions on this list, but I must admit
> I'm probably a too much down to earth tech guy to fully appreciate them.
> Therefore, it's possible I miss some of the fine nuances or problems in them.
> My basic interest is trying to translate the problems I see into (meta)
> protocol. Exact nomenclature and syntax, e.g. "domain" or "service", "access"
> or "caps", I prefer leaving to those better called to define it. I hope this
> doesn't cause too much confusion.
>  
> My basic suggestion of a handshake protocol permitting policy decisions (http:/
> /www.ietf.org/mail-archive/web/ogpx/current/msg00475.html) could (strictly
> technically) handle the debated issues of authentication, "adult content" and
> TOSes:
>  
> Agent domain:
> request access for
> Using this method, one could decide to let the agent domain manage the
> acceptance of "adult content" entirely, by the region domain not asking for age
> but let the agent domain automatically set accept for e.g. "adult content",
> "nudity", "sexual acts" and "profane language" to NO for those underage and as
> options YES/NO for those of age. One could also either ask for acceptance of
> "adult content" in general or for more specific parameters often associated
> with "adult content", giving great flexibility in policy making. But once
> again, that is policy outside protocol level.

but what is the mature age is a function of country, and thus region,
not agent domain. Adding to the protocol the notion of 'adult', so that
the RD can ask the AD 'is this person an adult?' won't work for that
reason.

Better to ask the AD, 'does the age of the person fall in this range?',
and even better to not define 'age' in the protocol, but just describe
how the RD can ask for 'does X falls into this range', where the AD
first tells the RD that it supports X (see my previous post).

>         "In order to have rights beyond "guest" on this region, you, or your
> agent domain, on your behalf, needs to have signed the TOS document. I will
> i think i grok what you're trying to say here, but i would also add... "a given
> agent domain MAY choose to deny you ANY service (including anonymous or guest
> access) if you don't provide some form of authenticator and assert that you
> have read and understand the domains terms of use."
>  
> - -cheers
> - -meadhbh
>  
>  
> wsBVAwUBSssVoe5MlU9XyaiSAQjgswgApysemtDE8npKhTSCUGHMxFnGxsdUvJfs
> /4z6Iribd7w2lmD20cx8xUB1/ojV5ABEEArCRdJmWbf5aGHBeF8nrv8cxlFOxWYB
> 37cZmEY7zAwbY6XNGB0NIpG2rnZWSW9sGJUOwVs4lW/DJKcDmuqgywtwtl5705u8
> W3G8y06I4sek/oukgGczqBBIG2Zny1qgbP/fr2AsewrHXYfYlMN2HnmzxQR60vry
> wJuV+gBe8RVC/ppHH+carOLMTmwZP8jbGnCy3+wUwI5H8+QbUuptdYNnJ8Fw0F/u
> yC2IesKerMmIlF0Z2Q93GyzGo02mn4dviLINYZ0M9kNYXhEe3OkypQ==
> =S0LC

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Oct 2009 13:58:13 -0700

hmm.. okay. i like where we're headed here. carlo, what you're
recommending is similar enough to the use of a seed capability we
could almost call it the same design pattern. i like the idea of the
AD tell the RD something like, "hey... here's a list of keywords
describing concepts i'm concerned about." then having the RD respond,
"oh! you're concerned about <FOO>, well lemme tell you about <FOO>."
and then having the AD decide whether or not the RD's values for FOO
violate it's policy.

however. i'm not entirely certain we (linden) would use it all the
time, and here's why. the model we've been proposing is that AD's
would negotiate deals with RD providers and specify requirements and
policies in excruciating detail in legal documents. we would then use
the name (domain name or subject name from the client cert) to lookup
what we think the policy would be, and then act on it.

but...

i still like this scheme because a) it's really similar to the way
seed caps work, b) it adds flexibility to our system(s), and c) it
does what i was hoping... gives the AD the ability to make policy
decisions (like am i going to let this 15 year old user access
material that may land me in hot water with the local authorities.)

so... what we could do is make the request optional, but the response
manditory. this would mean we could still use the deployment model
listed above, but the "tourist" model can use the request. (i'm using
the term "tourist model" to mean where someone's AD attempts to place
an avatar in a region the AD does not have a previous trust
relationship with.)

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Oct 2009 14:07:58 -0700

oh. hey. so i was just thinking about the "should we define global
keys for region meta-data?" question.

i think if we were to move forward with the AD telling the RD what
it's concerned about plan, we _should_ have global identifiers. i just
think that if everyone had different identifiers for the same concept,
you would get protocol interop, but you would still have systems that
don't know what each other are talking about.

but i totally get the idea implementing age restriction to mature
regions would be made difficult by the jurisdiction question.

but then i was thinking. what if we defined policies with well known
URIs? that way we (linden) could define names for policies like
"http://lindenlab.com/vwrap/policy/age" while someone else could
create a policy like "http://example.com/p/anglican".

anyway. just a though. i'm going to spend a little time trying to
understand a couple different country's regulations for online access
to adult materials by minors, just to get a sense for where the
differences would lie.

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Wed, 7 Oct 2009 22:51:20 +0100

Vaughn, I like your analysis here.

If rough consensus can be achieved around your point as a design decision, I
think it would remove a large hurdle to progress in regards to filtering and
prohibition semantics.  It would also reduce our workload immensely.

I don't think that I can improve on your analysis, but I can shorten your
wording:

*Policies are only advisary, and not enforced by the protocol.  Failure to
comply with a policy is therefore addressed out of band by non-protocol
means.*

Given this design decision, we would no longer have to worry about semantic
filters and policy blocks which are virtually impossible to get right, and
which would require us to create and manage a *security framework* -- a
major difficulty and source of problems.

Also, this ties in perfectly with what many people have said about "trust
agreements" --- that in the end they come down to courts, lawyers and
contracts, none of which are entities in an IETF protocol which at best
provides authenticated endpoints.

If no such consensus can be found, then I see years of semantic battles
ahead, and in particular a war between those who envisage creating
protocol-enforced prison planets versus those who envisage a metaverse that
by and large operates through emergent behaviour and dynamic consensus, in
the manner of the Internet.

Morgaine.

======================================

On Wed, Oct 7, 2009 at 7:12 PM, Vaughn Deluca <[email-masked]>wrote:

> If the policy of that AD is allowing, or even encouraging, the use of
> deadly weapons,  while I like my regions to be free of violence. I can
> ignore the policy of the agents AD. I am free to do so, and apply a policy
> of "ban on the first sight of a gun", after all I run this service. Ignoring
> the policy of the AD may carry the consequence of spoiling my relations with
> that AD, since they strongly belief in the freedom to carry weapons, and
> this may prompt them to prevent any TP to my RD. Yet that is about all thats
> in the power of the AD, unless it has some legal hooks in my service via a
> real world contract with me.
>
> Policy can be ignored, or followed, and its up to those setting the
> policies to enforce them, by whatever means they have at their disposal, but
> it has nothing to do with the protocol as such.
>
> We could (and probably should) have some discussion how far we want to go
> in facilitating certain use-cases by defining explicit fields to make
> interop easy. Not many will defend a pre-defined field for real-life skin
> color to allow other services more easy discrimination. But *even* if we had
> the (in my eyes) bad taste to define such a field or tag to aid some (in my
> eyes) unacceptable use-case, we are certainly NOT going to REQUIORE its use
> in the protocol, nor saying it MAY NOT be carried ever, since however wrong
> we think such a tag might be, it is a matter of policy, and as such outside
> the scope of the protocol. If we decided in this group that such a tag
> should be forbidden, and MUST NOT be carried we open the gates for demands
> that other tags must also be forbidden. And conversely, if we REQUIRE the
> use of such a tag, we can not prevent others in this discussion to REQUIRE
> other tags. And everything will end in tears.
>

---

From: Joshua Bell <[email-masked]>
Date: Wed, 7 Oct 2009 15:13:40 -0700

> don't know what each other are talking about.

Thinking while I type here - these aren't finished thoughts, just some
brainstorms:

So fundamental to this, we're talking about one system making policy
decisions based on data from another system that's in a different trust
domain (e.g. separate organizations). That implies to me that they must have
done an out-of-band trust negotiation, otherwise they have no reason to, er,
trust the data, so the policy decision is advisory at best. And at that
point, wouldn't we assume they're attempting to actively enable system
interop and would therefore also have that opportunity to agree on a
concept/identifier set? IMHO, that wouldn't live in the protocol itself, but
perhaps a standard set of interchange profiles...

Sample scenario (using the VW1=AD1+RD1, VW2=AD2+RD2 rough terminology we've
been batting about):

VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit RD2).
VW2 has a policy that they only allow in users of a certain quality (e.g.
"speaks Latin"). Only a subset of AD1 agents have that quality. Therefore,
RD2 would only accept teleports of AD1 agents that have that quality (based
on the sort of handshake discussed earlier in this thread). However, RD2
needs some trust relationship with AD1, otherwise malicious AD3 can come
along which claims all of its users speak Latin and its users slip in. So
VW1 and VW2 trade keys and sign some paperwork, and at that point (while the
lawyers are busy) they could handshake on sharing "agent linguistic
information profile v2.3" data.

On the other hand, there might be more hard-core requirements (age, security
clearance, etc) that would use different profiles.

Hopefully there's also the nil-trust case where this information might be
shared on a purely informational basis - e.g. even ADx asserts some quality
about an agent to RDy, ADx feels comfortable broadcasting that information
(since it can't trust that RDy will keep it confidential) and RDy feels
comfortable using that information even without trusting it (since it has no
reason to believe ADx is telling the truth).

Now... this all doesn't sound like it should new. I'm vaguely reminded of
W3C's PICS (which died quietly after negligible adoption), but there weren't
two active (and potentially liable...) entities involved in that, just the
single provider and user. Surely there are other examples?

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Oct 2009 15:30:26 -0700

i think there might be some confusion on what we're using the term
"policy" to mean.

when i use the term with respect to VWRAP, i do not mean a type of
policy like "please, no guns." i mean a policy such as "i (as a region
domain) will only place avatars from this list of agent domains," or
"i will not respond to LLSD messages encoded using the binary
serialization."

so in this sense, policy is not something imposed on you by a third
party, but a collection of decisions you (as a service operator) make
about how your service will behave. this is why i say things like
"domain sets policy," because in many cases, the domain's authority
may make a decision (like "i'm not going to accept MD5 hashed
passwords" or "i won't accept connections from non-authenticated third
parties" that will be global decisions.

that being said, you could have these policies dictated to you by a
third party, perhaps because they're paying you money or offering you
a service. but other than to acknowledge that it might happen, i don't
think it's in our best interest to define a protocol for transporting
policy descriptions between domains. what policies are possible will
differ between implementations, and the purpose of defining them as
part of the policy domain is to explicitly remove them from
negotiation during protocol exchanges.

-cheers
-meadhbh

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Thu, 8 Oct 2009 01:17:01 +0000

Meadbah wrote:

I may be mis-understanding all this since I'm still trying to come up to speed but isn't it the region that's making the policy decision here to allow/disallow a connect given what AD is representing about the user?  And yes, I agree that for this to work there must be trust established between the services involved.  I'm just confused by the above statement since it implies the AD is making a policy decision while it's really the RD that has the content (and hence the possible issue).  And the RD and AD may be run by two different entities....

Mike

---

From: Morgaine <[email-masked]>
Date: Thu, 8 Oct 2009 04:34:01 +0100

On Wed, Oct 7, 2009 at 11:13 PM, Joshua Bell <[email-masked]> wrote:

>
> VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit
> RD2). VW2 has a policy that they only allow in users of a certain quality
> (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality.
> Therefore, RD2 would only accept teleports of AD1 agents that have that
> quality (based on the sort of handshake discussed earlier in this thread).
> However, RD2 needs some trust relationship with AD1, otherwise malicious AD3
> can come along which claims all of its users speak Latin and its users slip
> in. So VW1 and VW2 trade keys and sign some paperwork, and at that point
> (while the lawyers are busy) they could handshake on sharing "agent
> linguistic information profile v2.3" data.
>

That's a great description of the ultimate interop dystopia in which,
through definition of arbitrary set membership criteria by an arbitrary
number of policy makers, the result of transitive policy transference and
policy intersection is that the set of visitable worlds is the empty set.

Are we trying to create an interop protocol here, or a protocol for
preventing interop?

I'm leaning ever more strongly towards David's position that only services
should carry expressions of policy, not domains, because in the direction in
which this discussion is heading there will be no widespread interop at all.

Imagine if SMTP had been specified to manage a set of content-defining
keywords and to block anything unacceptable to an MTA's "policy" based on
such tagged content.  And then (this is the killer), imagine if *sources of
email had to adhere to such tag policies transitively*.  There would either
be no email except from closed groups, or the whole tagging thing would be
such a farce that it would be ignored.

For now, I'm affirming even more strongly Vaughn's principle of *advisary
policy only*  ---
http://www.ietf.org/mail-archive/web/ogpx/current/msg00524.html .  Anything
else is a recipe for building walled gardens and widespread denial of
interop through contagion.

Morgaine.

==========================================

On Wed, Oct 7, 2009 at 11:13 PM, Joshua Bell <[email-masked]> wrote:

> On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick <[email-masked]
> > wrote:
>
> VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit
> RD2). VW2 has a policy that they only allow in users of a certain quality
> (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality.
> Therefore, RD2 would only accept teleports of AD1 agents that have that
> quality (based on the sort of handshake discussed earlier in this thread).
> However, RD2 needs some trust relationship with AD1, otherwise malicious AD3
> can come along which claims all of its users speak Latin and its users slip
> in. So VW1 and VW2 trade keys and sign some paperwork, and at that point
> (while the lawyers are busy) they could handshake on sharing "agent
> linguistic information profile v2.3" data.
>
> On the other hand, there might be more hard-core requirements (age,
> security clearance, etc) that would use different profiles.
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 7 Oct 2009 22:36:46 -0700

the way that my employer plans to deploy AD's and RD's is that the AD
will be the entity that has a relationship with the user. _it_ is
responsible for ensuring that the little ones don't run afoul of the
local obscenity regulations, because _it_ is the one that provides
access to the regions.

we _could_ say that it's the region's responsibility to know the agent
domain's policy, and that the region needs to block access to the user
when the agent domain tells it that the user in question is underage,
but that's the scenario we were trying to avoid: leaking information
about the user to the region domain. also, i think under current US
law, this might change the relationship between the RD and the AD with
respect to the nature of agency between the two. but, IANAL, so i'm
not an expert on that topic.

but at the end of the day, if i'm an agent domain, and i have a user
whom i know is 15 and a US resident, i would really like to make the
decision myself about whether i even want to start rezzing the user's
avatar in a region. and to make that decision, i will want to know
what the region's maturity level is set to.

-cheers
-meadhbh / infinity

On Wed, Oct 7, 2009 at 6:17 PM, Dickson, Mike (ISS Software)
<[email-masked]> wrote:
> I may be mis-understanding all this since I’m still trying to come up to
> speed but isn’t it the region that’s making the policy decision here to
> allow/disallow a connect given what AD is representing about the user?  And
> yes, I agree that for this to work there must be trust established between
> the services involved.  I’m just confused by the above statement since it
> implies the AD is making a policy decision while it’s really the RD that has
> the content (and hence the possible issue).  And the RD and AD may be run by
> two different entities….
>
>
>
> Mike
>
>

---

From: Magnus Zeisig <[email-masked]>
Date: Thu, 8 Oct 2009 10:48:33 +0200

I am strongly in favour of leaving policy descisions to the RD, but since there seems to be a need for at least some AD managers to be able to make policy decisions as well, I guess the protocol handshake need even more flexibility than the versions scetched on by Meadhbh, Carlo and me so far. I will adapt the diagram style of Meadhbh and Carlo (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since it's more readable than my text-flow variant. Also, I will leave out parameter examples since there seem to be a risk people get hooked on if a certain parameter should be included or not, rather than the possibility of handling any parameter.

I may be paranoid, but I still prefer agent domains to be allowed, but not forced by protocol, to reduce the dissemination of information about their clients as far as possible, and there Carlo's AND version in the response is a good step forward (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We might even wind up with negotiations where one domain requests the actual values while the other domain only wants to disseminate a reply to if it fits a range for one or more of the requested parameters.

AD -------------------------(name, <RDkey1?, RDkey2?>)------------------------> RD
AD <--(name, <RDvalue1, RDvalue2, ADkey1?, ADkey2?, agentkey1?, agentkey2?>)--- RD
AD --(name, <RDvalues OK, ADvalue1, ADvalue2, agentvalue1, agentkey2 range?>)-> RD
AD <----------(name, <ADvalues OK, agentvalue1 OK, agentkey2 range>)----------- RD
AD ----------------------------(name, agentkey2 OK)---------------------------> RD
AD <-----------------------------(name, rez cap)------------------------------- RD

In this example, RD might have refused giving the required range for agentvalue2, either because it technically doesn't support that kind of negotiation or because of policy, in either case of which the rez cap would have failed. It might on the other hand instead already from the beginning have supplied the required ranges instead of asking for the actual value. I think it would be good if the protocol would enable either of these cases for maximum flexibility.

It may also be an idea to permit caching of at least AD- and RD-parameters or evaluations of them, especially if we're talking extensive sets with perhaps hundreds of parameters. Since the ADs and RDs should be free to update their own parameters at any time, the handshake in that case must of course contain a check if cached parameters have been updated. Also, if an AD or RD supports several sets of parameters depending on which domain or service it deals with, means to distinguish between them are required, perhaps using policy URI's the way Meadhbh suggested (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A policy could then basically be broken down into a set of own parameter values and required parameter ranges for the domain or service connecting.

I also think, like Meadhbh (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we will need to suggest, but not require, a number of parameter name and formats to facilitate communication, so that not e.g. US and UK domains can't connect, because one asks about "color" and the other one only can respond about "colour".

Best regards,

Magnus

- -----Ursprungligt meddelande-----
Från: Carlo Wood [mailto:[email-masked]]
Skickat: den 7 oktober 2009 22:36
Till: Infinity Linden
Kopia: Magnus Zeisig; [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

or some might implement

or,

- --

---

From: Morgaine <[email-masked]>
Date: Thu, 8 Oct 2009 10:41:54 +0100

Magnus,

If ADs are involved in region policy, then in the multi-world deployment
pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to
RD2, because AD2 will be involved in region policy too.  It's symmetric with
AD1.

This is what Joshua wanted to avoid, and it can only be avoided by not
giving ADs policy control over regions, otherwise symmetry requires that AD2
be consulted as well.

It's this kind of problem that reinforces what David's been saying about the
right mess we currently have when talking about domains determining policy.
The AD/RD split was reasonably adequate when OGP was only extending a single
world with policy-free regions, but it is insufficient to do a good job once
we get into multi-world deployments with more complex service and policy
patterns which require much more flexibility.

Morgaine.

On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <[email-masked]> wrote:

> I am strongly in favour of leaving policy descisions to the RD, but since
> there seems to be a need for at least some AD managers to be able to make
> policy decisions as well, I guess the protocol handshake need even more
> flexibility than the versions scetched on by Meadhbh, Carlo and me so far. I
> will adapt the diagram style of Meadhbh and Carlo (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since
> it's more readable than my text-flow variant. Also, I will leave out
> parameter examples since there seem to be a risk people get hooked on if a
> certain parameter should be included or not, rather than the possibility of
> handling any parameter.
>
> I may be paranoid, but I still prefer agent domains to be allowed, but not
> forced by protocol, to reduce the dissemination of information about their
> clients as far as possible, and there Carlo's AND version in the response is
> a good step forward (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We might
> even wind up with negotiations where one domain requests the actual values
> while the other domain only wants to disseminate a reply to if it fits a
> range for one or more of the requested parameters.
>
> In this example, RD might have refused giving the required range for
> agentvalue2, either because it technically doesn't support that kind of
> negotiation or because of policy, in either case of which the rez cap would
> have failed. It might on the other hand instead already from the beginning
> have supplied the required ranges instead of asking for the actual value. I
> think it would be good if the protocol would enable either of these cases
> for maximum flexibility.
>
> It may also be an idea to permit caching of at least AD- and RD-parameters
> or evaluations of them, especially if we're talking extensive sets with
> perhaps hundreds of parameters. Since the ADs and RDs should be free to
> update their own parameters at any time, the handshake in that case must of
> course contain a check if cached parameters have been updated. Also, if an
> AD or RD supports several sets of parameters depending on which domain or
> service it deals with, means to distinguish between them are required,
> perhaps using policy URI's the way Meadhbh suggested (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A policy
> could then basically be broken down into a set of own parameter values and
> required parameter ranges for the domain or service connecting.
>
> I also think, like Meadhbh (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we
> will need to suggest, but not require, a number of parameter name and
> formats to facilitate communication, so that not e.g. US and UK domains
> can't connect, because one asks about "color" and the other one only can
> respond about "colour".
>
> Best regards,
>
> Magnus
>
>
> Från: Carlo Wood [mailto:[email-masked] <[email-masked]>]
> wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL
> JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/
> cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ
> RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm
> tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd
> 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w==
> =2NSu

---

From: Magnus Zeisig <[email-masked]>
Date: Thu, 8 Oct 2009 12:30:20 +0200

Morgaine,

No, you are still stuck in the concept of one virtual world equals one AD plus one RD, even if you say you recognize a future more complex service pattern. VW=AD+RD does not have to be the case with VWRAP. If it _happens_ to be the case and the entity controlling AD2 and RD2 wants to enforce AD2 policy for those visiting RD2, then they can move, duplicate or mirror the enforcement of that policy from AD2 to RD2, which they can do without problems as long as they control both. If they don't control both, then it's entirely up to the entity controlling RD2 if they for some reason want to enforce the policy of the entity controlling AD2. So I see no reason whatsoever why symmetry is required.

Policy is not decided and enforced by the AD, the RD or any service connected with them, it is decided and enforced by the entities behind them. If the same entity controls an AD and a RD, then it's meaningless to try to divide up that entity's policy into AD policy and RD policy, because it can enforce that policy at any level, type of domain or connected service it controls.

But, like you, I am totally in favor of letting the entity controlling the destination RD decide policy once the agent is there. However, if the agent's own AD for some reason wants to stop the agent from going there, then I think it should have the possibility to do so. In all honesty, I don't think an AD imposing undue restrictions on where people are allowed to go or what they are allowed to do there will survive for long though, once competition is in place. You may have to start out fresh, with a new AD, without the assets and inventory connected to the old AD, but I think most people are willing to take that step if they feel their freedom is too limited.

Best regards,

Magnus

-----Ursprungligt meddelande-----
Från: Morgaine [mailto:[email-masked]] 
Skickat: den 8 oktober 2009 11:42
Till: Magnus Zeisig
Kopia: [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

Magnus,

If ADs are involved in region policy, then in the multi-world deployment pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2, because AD2 will be involved in region policy too.  It's symmetric with AD1.

This is what Joshua wanted to avoid, and it can only be avoided by not giving ADs policy control over regions, otherwise symmetry requires that AD2 be consulted as well.

It's this kind of problem that reinforces what David's been saying about the right mess we currently have when talking about domains determining policy.  The AD/RD split was reasonably adequate when OGP was only extending a single world with policy-free regions, but it is insufficient to do a good job once we get into multi-world deployments with more complex service and policy patterns which require much more flexibility.

Morgaine.

	
	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256

	 

	 
	 
	Best regards,
	 
	Magnus

	 

	 

	 
	or some might implement

	 
	 
	or,

	 
	- --

---

From: Magnus Zeisig <[email-masked]>
Date: Thu, 8 Oct 2009 12:38:48 +0200

In the future I think we will have a VWRAP metaverse similar to how the web works today. The VWRAP protocol will enable both private persons and major organizations to set up and interop, to the degree each entity wants, their own corner of the virtual world with the rest of that world. Just like on the web, we will see entities running "intra-metaverses", totally shut off or only to a limited degree open to the public. We will probably also see attempts by some major entities, just like e.g. Microsoft Network, to set their own standards and believe they are big enough to force others to adapt to those standards, and we will probably, just as was the case with Microsoft Network, see those attempts fail.

In the beginning, there will probably be a few major players with a head starts and server parks, and a multitude of small players, running their pieces of the virtual world using e.g. OpenSimulator, on their desktop or laptop computers. Many of the small players will probably have the very simple policy of "If you want to connect, welcome, regardless of your credentials, but if you misbehave I will kick you out." In time, some of those small players will grow because they serve interesting content or create social networks with many users/visitors. Most of them will probably see a need to develop more strict policies to enable administration of their services at all, so they don't have to spend all day kicking abusers returning time after time with new identities, disrupting the experience for other users.

Those service and domain managers requesting some kind of trust domain to allow others using or connecting to their services and domains will either cut themselves off from all those small players running their domains or services home in their kitchen or cupboard, ease up on their demands for domains of trust, or simplify the procedure so that the necessary domain of trust can be established via electronic signatures on the first connection. If they choose to remain cut off from the rest of the metaverse, they will probably soon be forgotten islands in the sea of tens or hundreds of thousands minor domains and services interoping more freely.

The point is that the VWRAP protocol will not proscribe how you should run your service, open or as a walled garden, small or big. It will permit you to interop to the degree you chose yourself, not forcing you to interop any more or less than that. Other factors, like international law, national legislation, ISP TOS, organization policies and such, may force you to set limitations or raise requirements on with who and how you interop, but VWRAP should offer you the tool to do so, regardless of if you want, or are forced, to run a strictly regulated walled garden alone or including a few trusted peers, by supporting the communication needed for policy-enforcement, or run a no-holds-barred free-for-everyone operation, by not requiring the use of any policy-support whatsoever.

Best regards,

Magnus

Magnus,

Morgaine.

---

From: Carlo Wood <[email-masked]>
Date: Thu, 8 Oct 2009 13:44:35 +0200

> to adult materials by minors, just to get a sense for where the

Although admirable, this is just an EXAMPLE. We should look at it,
and SOLVE it, in an abstract way; so that we will tackle every
possible policy problem like it without that we have to think of
an exhausted list now.

Ie, if your investigation would show that every country in the
world handles online access to adult materials by minors in the
exact same way, than that doesn't make the abstract problem go
away, we'd just have to think of another example to tackle the
exact same problem.

---

From: Morgaine <[email-masked]>
Date: Thu, 8 Oct 2009 13:32:15 +0100

Magnus, you're mixing up my analysis of what's required for Joshua's scheme
to work, with my recognition that we need a more flexible approach based not
on this restrictive AD+RD split but on the much more flexible decoupled
services behind them.

When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is *not at all  *the
actual deployment scenario that any of us expects to see.  It's just the
smallest case that allows us to say something concrete about the problems
with the original OGP design when extrapolated to the multi-world deployment
scenario.  So please don't attribute any narrow vision in this scenario to
me --- I'm fully aware that it's artificial and is going almost nowhere.
I'm merely doing a smallest-possible scenario analysis.

My personal interest is in the fully expanded and massively scaled
deployments which the AWG group in SL was originally formed to consider 2
years ago (this might give you some idea of the scale ---
https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no point
describing a massively complex deployment example when a simpler one
suffices to make a specific point. :-)

So to your post ...

On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <[email-masked]> wrote:

> Morgaine,
>
> No, you are still stuck in the concept of one virtual world equals one AD
> plus one RD, even if you say you recognize a future more complex service
> pattern. VW=AD+RD does not have to be the case with VWRAP.

I know that it's artificial.  We're merely examining this small scenario to
highlight an elementary problem with distribution of services, and it has
already been useful.  It has demonstrated that even in this miniscule
example, there need to be (i) asset service contributions from *both* worlds
in the example, so just a single inventory service in AD1 is not adequate,
and (ii) that if ADs control region policy then AD2 must be consulted as
well since it has every bit as much right to determine policy in RD2 as does
AD1, or more.  These are important constraints on the design, despite the
deployment example being such a simple one.

In addition to the case shown, there are simpler cases and there are more
complex cases.

The simpler cases, such as no AD2 exists, or only W1 asset services are used
in W2, can be handled by the original OGP design, so they wouldn't have
served the purpose here.  More complex cases, such as multiple RDs in W2, do
not add value to the particular point being made, so why complicate the
scenario unnecessarily?  We'll certainly need them later, but they don't
help here.

Obviously multi-world deployment scenarios such as we expect to be common in
the metaverse are going to have much more complex deployment patterns
involved a myriad of concurrent services, but adding that complexity at this
point doesn't enhance the present argument.

If it _happens_ to be the case and the entity controlling AD2 and RD2 wants
> to enforce AD2 policy for those visiting RD2, then they can move, duplicate
> or mirror the enforcement of that policy from AD2 to RD2, which they can do
> without problems as long as they control both. If they don't control both,
> then it's entirely up to the entity controlling RD2 if they for some reason
> want to enforce the policy of the entity controlling AD2. So I see no reason
> whatsoever why symmetry is required.
>

Ah, here you've simply misunderstood me:  you think I'm talking about *
deployment* symmetry, but I'm not.  I'm talking about
*definition*symmetry:  if ADs are defined to be able to control region
policies, then by
symmetry that applies to all ADs.  It wouldn't make sense to say "ADs are
defined to carry region policy, but this only applies to our ADs and not to
yours."  ;-)  That's what I mean by this applying symmetrically.

Deployment patterns are of course arbitrary and don't have to be
symmetrical:  two interoperating worlds can individually be using any
deployment pattern they choose, and one world of the pair will generally
have no say on the deployment pattern used by the other.  Across the whole
metaverse, we can expect every single possible deployment pattern to be used
by someone, and for added spice, tourists from every possible deployment
could be visiting some common tourist world to create a kaleidescope of
combined deployments in the region.

> Policy is not decided and enforced by the AD, the RD or any service
> connected with them, it is decided and enforced by the entities behind them.
> If the same entity controls an AD and a RD, then it's meaningless to try to
> divide up that entity's policy into AD policy and RD policy, because it can
> enforce that policy at any level, type of domain or connected service it
> controls.
>

Sure, but someone has to code this stuff.  It's not helpful to say "Anything
can be done anywhere", because that would mean that the protocol would at
every decision point have to gather policy contributions from all possible
endpoints.  It *can* be done this way of course, but if a simpler design
suffices then a more compex one may not be a good idea.

That said, take note of David's advice about policy being best implemented
in the services themselves.  Domains are not necessarily bad, but they do
actually restrict our flexibility substantially compared to using decoupled
services alone.

>
> But, like you, I am totally in favor of letting the entity controlling the
> destination RD decide policy once the agent is there. However, if the
> agent's own AD for some reason wants to stop the agent from going there,
> then I think it should have the possibility to do so. In all honesty, I
> don't think an AD imposing undue restrictions on where people are allowed to
> go or what they are allowed to do there will survive for long though, once
> competition is in place. You may have to start out fresh, with a new AD,
> without the assets and inventory connected to the old AD, but I think most
> people are willing to take that step if they feel their freedom is too
> limited.

Well in my case I'm not merely "*in favour*" of region policy control by
regions.  I don't think it's actually optional in multi-world deployments,
because without Destination Determines Destination Policy there can be no
viable multi-world tourism at all, and that's the primary use case with
massive popular interest.  We wouldn't have much of a metaverse without it.

Morgaine.

On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <[email-masked]> wrote:

> Morgaine,
>
> No, you are still stuck in the concept of one virtual world equals one AD
> plus one RD, even if you say you recognize a future more complex service
> pattern. VW=AD+RD does not have to be the case with VWRAP. If it _happens_
> to be the case and the entity controlling AD2 and RD2 wants to enforce AD2
> policy for those visiting RD2, then they can move, duplicate or mirror the
> enforcement of that policy from AD2 to RD2, which they can do without
> problems as long as they control both. If they don't control both, then it's
> entirely up to the entity controlling RD2 if they for some reason want to
> enforce the policy of the entity controlling AD2. So I see no reason
> whatsoever why symmetry is required.
>
> Policy is not decided and enforced by the AD, the RD or any service
> connected with them, it is decided and enforced by the entities behind them.
> If the same entity controls an AD and a RD, then it's meaningless to try to
> divide up that entity's policy into AD policy and RD policy, because it can
> enforce that policy at any level, type of domain or connected service it
> controls.
>
> But, like you, I am totally in favor of letting the entity controlling the
> destination RD decide policy once the agent is there. However, if the
> agent's own AD for some reason wants to stop the agent from going there,
> then I think it should have the possibility to do so. In all honesty, I
> don't think an AD imposing undue restrictions on where people are allowed to
> go or what they are allowed to do there will survive for long though, once
> competition is in place. You may have to start out fresh, with a new AD,
> without the assets and inventory connected to the old AD, but I think most
> people are willing to take that step if they feel their freedom is too
> limited.
>
> Best regards,
>
> Magnus
>
>
> It's this kind of problem that reinforces what David's been saying about
> the right mess we currently have when talking about domains determining
> policy.  The AD/RD split was reasonably adequate when OGP was only extending
> a single world with policy-free regions, but it is insufficient to do a good
> job once we get into multi-world deployments with more complex service and
> policy patterns which require much more flexibility.
>
>
> Morgaine.
>
>
>
>
>        I am strongly in favour of leaving policy descisions to the RD, but
> since there seems to be a need for at least some AD managers to be able to
> make policy decisions as well, I guess the protocol handshake need even more
>        I may be paranoid, but I still prefer agent domains to be allowed,
> but not forced by protocol, to reduce the dissemination of information about
> their clients as far as possible, and there Carlo's AND version in the
> response is a good step forward (
>        It may also be an idea to permit caching of at least AD- and
> RD-parameters or evaluations of them, especially if we're talking extensive
> sets with perhaps hundreds of parameters. Since the ADs and RDs should be
> free to update their own parameters at any time, the handshake in that case
> must of course contain a check if cached parameters have been updated. Also,
> if an AD or RD supports several sets of parameters depending on which domain
> or service it deals with, means to distinguish between them are required,

---

From: Magnus Zeisig <[email-masked]>
Date: Thu, 8 Oct 2009 14:39:26 +0200

Heh, don't worry about finding out regulations about adult material is the same all over the world. I've been at that can of worms myself, and there are places where it's regulated or not, different ages, from 13 (the lowest age I know of) to forbidden for "adults" as well, different definitions of what's included and not, different type distinctions and degrees permissible. Some places support law suits against publishers in other places even if it's perfectly legal at the publisher's home location, and so on.

But you are quite right in that we shouldn't stare ourselves blind at special cases like adult content, but find general mechanisms to handle policy negotiation in the VWRAP protocol. The actual policy decisions should, as stated many times before, be outside the protocol. I think some important questions in that respect may be if such mechanisms
1. need to be different from exchanging other information?
2. require any special support for exchanging credentials like e.g. electronic signatures?
3. need to serve also services other than AD and RD?
4. require any special infrastructure like separate DTDs, machine readable policy documents or the like?
5. should facilitate automatic setup of trust domains?

Best regards,

Magnus

- -----Ursprungligt meddelande-----
Från: Carlo Wood [mailto:[email-masked]]
Skickat: den 8 oktober 2009 13:45
Till: Meadhbh Hamrick
Kopia: Magnus Zeisig; Infinity Linden; [email-masked]; [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

- --

---

From: David W Levine <[email-masked]>
Date: Thu, 8 Oct 2009 09:57:04 -0400

One thing to keep in mind in this whole discussion is the following: "All 
policy decisions are local" This doesn't mean they don't represent a way 
of solving a globally distributed use case, but
it highlights the fact the one software element, hosted behind and 
endpoint can't impose behavior on another such endpoint. In the case of 
how a service in an Agent Domain interacts with the services in a region 
domain, the Agent Domain is limited to controlling what *it* does. So, in 
the case of an agent domain which has the policy of not permitting its 
users to be exposed to "mature" content. The agent domain, however, 
doesn't perform the delivery of content from the region. It handles 
authentication, and global presence management, and possibly inventory 
management, but, it doesn't control what happens in the region. (In fact, 
in the current model, it doesn't even see the traffic, but seeing it 
wouldn't help) 

The decision as to what happens inside the region is local to the region. 
Just as the agent Dorian in this example doesn't see what the region is 
doing, the region doesn't see what the
agent domain is doing, nor can it influence it.

>From the point of view of the use case "Keep my agents away from "mature" 
content" the Agent Domain's leverage is limited to looking at the 
information the region exports, and deciding whether or not this is a 
region where it is safe for its agents to travel. The region, of course, 
can say whatever it wants. So.. if the Agent Domain wants certainty, it 
needs for the
region to not only export information it can use to make this decision, 
but to export it in a way that gives the agent domain increased certainty. 
 Traditionally, this takes the form of a
digital signature tied to real world, out of band assurances. 

I would argue this is all for the good. At the Protocol and Endpoint 
description level, most of what needs to happen to support this model is 
to make sure we know where services expose meta-data and how it is 
formatted. The protocol need not focus on what the meta-data represents, 
but that it is there and available for supporting policy decisions. 

>From the perspective of managing interop, I think that the bulk of our 
focus needs to be having the use cases which enable us to make sure we 
*can* export and understand
the meta-data needed to allow policy decisions to be made. 

There is a related topic, namely how we might do a distributed policy 
language permitting various services to reason about the policies 
governing a given service they wish to interact with. But.. That's not 
needed to make the protocol work. I view this as a good thing, since it is 
a decidedly non trivial problem to solve. 

I would suggest that one good way forward on this is to develop a set of 
policy use cases to drive our analysis of the protocol and specifications, 
and then look at whether we can reasonably manage these use cases.  My 
personal belief is that the bulk of our policy management is going to 
consist of checking for meta-data signed using existing PKI standards 
(x.509  is the obvious one) and making decisions based on this meta-data. 

- David W. Levine
~ Zha Ewry

10/08/2009 07:44 AM

To
Meadhbh Hamrick <[email-masked]>
cc
Infinity Linden <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, Magnus Zeisig 
<[email-masked]>
Subject
Re: [ogpx] Protocol for permitting policy decisions

---

From: Magnus Zeisig <[email-masked]>
Date: Thu, 8 Oct 2009 16:41:07 +0200

Morgain, I believe we're not that far off from each other, even if I think the example you presented was not appropriate and I still can see no reason for your symmetry in AD/RD requests. The latter notion has already been commented upon by others in more detail. But like you, I also think it's reasonable to leave or generalize away from the thought of domains and rather use services as protocol endpoints. Regardless of if we talk about domains or services, I think the basic negotiation pattern will always be the same:

Client: I want your services but (may) have some (policy) demands to use them.
Server/Service: I offer you my services but (may) have some (policy) demands to let you use them.

Both client and server/service can be the agent or region domain, user/agent, authentication, presence, asset, inventory, simulation, voice or movie service, or any other domain or service you can think of, standalone or clustered in any combinations depending on technical issues, ownership and agreements.

So, when any client (C) requests any service from a server/service (S), it may look like this, if all work out:
C ---(id, service?, S policy?)--> S
C <--(id, S policy, C policy?)--- S
C --(id, S policy OK, C policy)-> S
C <-(id, C policy OK, service)--- S

Policies in this case may refer both to things like data format (mesh format, image format) and data classification (adult, require IP agreements). The acceptance of policies, permitting the service performed, from both C and S, may be negotiated directly between C and S, or between servers/services connected to C and S respectively, negotiated at the time of service request and/or stored in some form of access, token or cap, at C and/or S respectively, or servers/services connected to them.

If C and S are controlled by the same entity, that entity may use any way, including VWRAP, to negotiate and deliver the service, and the policy part may be left out from the negotiation, e.g. because the entity use the same policy for all services controlled.

If C and S are controlled by different entities, those entities may use any way, including VWRAP, to negotiate and deliver the service, and the policy part may be left out from the negotiation, e.g. because the entities have an already established agreement (format agreement, domain of trust) or don't require one.

If the policy negotiation is left out, the request becomes:
C --(id, service?)-> S
C <-(id, service)--- S

To support a flexible new infrastructure with many different domains or services interacting in many different constellations, including interop between the "classical" virtual worlds of today, VWRAP should be able to treat any service request and/or policy negotiation the same or very similar, regardless of endpoints and endpoint types. The endpoints will mutually decide if to use VWRAP and to which extent. VWRAP should however be an attractive enough way to handle the communication to be a first hand choice, both between clients and servers/services of the same as well as different entities. One advantage of using VWRAP will then be that outsourcing, exchange or addition of services will be easy, since basically just addresses of servers/services will need to be changed and transfer of old data to the new services be performed.

I know that some of the things above have already been stated on the list, but I'm repeating them just for the clarity of argumentation.

Best regards,

Magnus

-----Ursprungligt meddelande-----
Från: Morgaine [mailto:[email-masked]]
Skickat: den 8 oktober 2009 14:32
Till: Magnus Zeisig
Kopia: [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

Magnus, you're mixing up my analysis of what's required for Joshua's scheme to work, with my recognition that we need a more flexible approach based not on this restrictive AD+RD split but on the much more flexible decoupled services behind them.

When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not at all  the actual deployment scenario that any of us expects to see.  It's just the smallest case that allows us to say something concrete about the problems with the original OGP design when extrapolated to the multi-world deployment scenario.  So please don't attribute any narrow vision in this scenario to me --- I'm fully aware that it's artificial and is going almost nowhere.  I'm merely doing a smallest-possible scenario analysis.

My personal interest is in the fully expanded and massively scaled deployments which the AWG group in SL was originally formed to consider 2 years ago (this might give you some idea of the scale ---  https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no point describing a massively complex deployment example when a simpler one suffices to make a specific point. :-)

So to your post ...

        Morgaine,

        No, you are still stuck in the concept of one virtual world equals one AD plus one RD, even if you say you recognize a future more complex service pattern. VW=AD+RD does not have to be the case with VWRAP.

I know that it's artificial.  We're merely examining this small scenario to highlight an elementary problem with distribution of services, and it has already been useful.  It has demonstrated that even in this miniscule example, there need to be (i) asset service contributions from both worlds in the example, so just a single inventory service in AD1 is not adequate, and (ii) that if ADs control region policy then AD2 must be consulted as well since it has every bit as much right to determine policy in RD2 as does AD1, or more.  These are important constraints on the design, despite the deployment example being such a simple one.

In addition to the case shown, there are simpler cases and there are more complex cases.

The simpler cases, such as no AD2 exists, or only W1 asset services are used in W2, can be handled by the original OGP design, so they wouldn't have served the purpose here.  More complex cases, such as multiple RDs in W2, do not add value to the particular point being made, so why complicate the scenario unnecessarily?  We'll certainly need them later, but they don't help here.

Obviously multi-world deployment scenarios such as we expect to be common in the metaverse are going to have much more complex deployment patterns involved a myriad of concurrent services, but adding that complexity at this point doesn't enhance the present argument.

        If it _happens_ to be the case and the entity controlling AD2 and RD2 wants to enforce AD2 policy for those visiting RD2, then they can move, duplicate or mirror the enforcement of that policy from AD2 to RD2, which they can do without problems as long as they control both. If they don't control both, then it's entirely up to the entity controlling RD2 if they for some reason want to enforce the policy of the entity controlling AD2. So I see no reason whatsoever why symmetry is required.

Ah, here you've simply misunderstood me:  you think I'm talking about deployment symmetry, but I'm not.  I'm talking about definition symmetry:  if ADs are defined to be able to control region policies, then by symmetry that applies to all ADs.  It wouldn't make sense to say "ADs are defined to carry region policy, but this only applies to our ADs and not to yours."  ;-)  That's what I mean by this applying symmetrically.

Deployment patterns are of course arbitrary and don't have to be symmetrical:  two interoperating worlds can individually be using any deployment pattern they choose, and one world of the pair will generally have no say on the deployment pattern used by the other.  Across the whole metaverse, we can expect every single possible deployment pattern to be used by someone, and for added spice, tourists from every possible deployment could be visiting some common tourist world to create a kaleidescope of combined deployments in the region.

Sure, but someone has to code this stuff.  It's not helpful to say "Anything can be done anywhere", because that would mean that the protocol would at every decision point have to gather policy contributions from all possible endpoints.  It can be done this way of course, but if a simpler design suffices then a more compex one may not be a good idea.

That said, take note of David's advice about policy being best implemented in the services themselves.  Domains are not necessarily bad, but they do actually restrict our flexibility substantially compared to using decoupled services alone.

Well in my case I'm not merely "in favour" of region policy control by regions.  I don't think it's actually optional in multi-world deployments, because without Destination Determines Destination Policy there can be no viable multi-world tourism at all, and that's the primary use case with massive popular interest.  We wouldn't have much of a metaverse without it.

Morgaine.

        Morgaine,

        Best regards,

        Magnus

        -----Ursprungligt meddelande-----

        Magnus,

        Morgaine.

               -----BEGIN PGP SIGNED MESSAGE-----
               Hash: SHA256

               Best regards,

               Magnus

               or some might implement

               or,

               - --

---

From: Carlo Wood <[email-masked]>
Date: Thu, 8 Oct 2009 17:47:01 +0200

On Thu, Oct 08, 2009 at 01:17:01AM +0000, Dickson, Mike (ISS Software) wrote:
> I may be mis-understanding all this since I’m still trying to come up to speed
> but isn’t it the region that’s making the policy decision here to allow/
> disallow a connect given what AD is representing about the user?  And yes, I
> agree that for this to work there must be trust established between the
> services involved.  I’m just confused by the above statement since it implies
> the AD is making a policy decision while it’s really the RD that has the
> content (and hence the possible issue).  And the RD and AD may be run by two
> different entities….
> 
> Mike

Mike is correct, at least -- that is the way I intended it :p

The AD gathers information about a user and tells the RD (in general terms)
what information it has. Then the RD tells the AD under what circumstances
the user can be allowed in (by giving a list of ranges (or values / reg.exp)
that the given data has to match.

In the end, the AD does not make the decision therefore.

If the authority that runs the AD has a moral problem with letting in
users of 15 into a mature region, then they can arrange in ADVANCE with
the administration of the region that it either 1) doesn't contain mature
content or 2) asks for an age > 18 (or whatever satisfies the AD administration).

The real-time protocol exchange and per-user decisions however, are then
in principle in the hands of the Region. That is a Good Thing.

---

From: Joshua Bell <[email-masked]>
Date: Thu, 8 Oct 2009 09:45:56 -0700

> Are we trying to create an interop protocol here, or a protocol for

:) Honestly, I was trying to riff on the thread (AD and RD sharing
information about agents to make policy decisions), rather than propose
anything. I think an attempt to define a global set of characteristics about
users that enable all policy decisions is hopeless - cultures, laws, and
individuals are too varied and rich. That leaves pair-wise negotiation
and/or trust networks, which IMHO needs to happen *if* there are to be
service-level distinctions for most cases anyway.

What I forgot to say is: on the Web, as you move between sites you accept
various terms of service. Attempts to have your browser automatically
negotiate with sites over content have been extremely limited - things like
the defunct PICS (you tell your browser to allow a third party site to rate
the site you intend to visit), or Google's features which block
malware/phishing sites (and I believe are used by current browsers as well
when you just type a URL). Your user-agent (Web browser) does *not* have a
built-in lawyer that agrees to a TOS on your behalf, however. (I'm having
flashbacks of "Diamond Age" here - is that the right novel?)

In the VWRAP space, I don't believe your VW agent domain will be capable of
doing that in a totally generalized, automated way either... so either it
will have some a priori knowledge of the RD via some manner (pair-wise
negotiation, trust network, etc), defer to the user to accept the TOS, or
simply block access.

In other words: "Just like the web, except where it's different" once again.

> which this discussion is heading there will be no widespread interop at all.

I need to re-read Meadhbh's drafts to internalize the formal terminology
(yeah, my bad), but in my head a "domain" is a deployment model for a set of
conceptually related services, but it's the service end-points that exist at
the protocol level. We talk about domains as clusters of conceptually
related services as a crutch so we don't have to enumerate the specific
services in each conversation.

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Thu, 8 Oct 2009 10:26:20 -0700

i wouldn't say that AD's are involved with region policy. i would say
that the AD's have a policy of not placing avatars in regions that do
not advertise certain metadata and the AD believes they can be
trusted.

getting back to the adult region example... let's say i'm an operator
of a shared virtual experience. i have a bunch of underage customers.
many of them have parents who both have money to pay lawyers and don't
want their kids getting access to "adult content." also, i advertise
my service in the united states, UK and other countries who have
regulations or laws limiting access to adult material by minors. my
policy, as a service operator, will probably very quickly become
"comply with local regulations and with foreign regulation as required
by international treaty to avoid criminal and civil liability."

so i have an agent domain, because i have a relationship with my
customers. i probably have several regions i operate on my own, but i
want to stitch my regions up with regions operated by happy funco
land, inc. (HFLI). HFLI operates an adults only service and there's
adult content on their grid. in the US, it doesn't matter that HFLI
operates the region. i was complicit in the act of connecting minors
to adult content online. i have the relationship with the customer.
guess who's going to get sued first?

what i may do in this case is tell HFLI that if they want my bazillion
users to connect to their land, they're going to have to segregate
adult content into specific regions and mark those regions with an
adults only maturity tag. before i place an avatar in that region, i
(as the agent domain operator) will look at the age of the user and
then look at the maturity tag on the region they want to teleport
into. if the region is tagged "adult" and my avatar is underage, i
will not try to rez their avatar. i do it this way because i really,
really, really don't want to open myself up to liability. i don't want
to depend on a foreign organization to enforce MY policy.

so, this is not an example where i (as the agent domain) is
interfering or setting the policy of a third party. i am not the
authority for that domain. what i _can_ do, however, is contract that
third party to follow certain procedural safeguards, and before
allowing my users to set virtual foot in their land, force them to
assume liability if they do not exercise due care in the execution of
their contractual obligations.

so this is a use case where we do not dynamically modify policy. we
negotiate a policy and behavior through legal channels before allowing
access from the AD to the RD. as the AD, i am not telling the RD
during the protocol negotiation phase what my policy requirements are.
i am not negotiating a policy at connect time. what i _am_ doing is i
_am_ looking at a trusted identifier for that RD (like a TLS server
certificate,) i am validating it, then i am doing a lookup in my
system to see if i trust them, then i am determining the policy with
regards to adult content on that region. if the policy is conformable
with mine, i begin the process of teleporting the user's avatar to
that region.

there are several ways to determine policy:

a. identity implies policy. maybe i happen to be connected to Dalt
Wisney and know that they are an exclusively "family oriented"
operation. ergo, i know i don't have to worry about adult material
being in those regions.

b. authenticator implies policy. maybe if we're using X.509
certificates, we've made a deal to stuff policy identifiers in the
X.509 certificates. sure, there are a lot of reasons NOT to do this,
but then again, maybe it works for some people.

c. region metadata implies policy. maybe when we access the region
meta data, there's a tag for "adult material here."

these are the options for the way we anticipate our service operating.
but i'm not prejudiced against the tourist model, so sure, let's
allow, but not REQUIRE AD's to go through this negotiation process if
we're in the virtual tourist model.

-cheers
-meadhbh/infinity

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Thu, Oct 8, 2009 at 02:41, Morgaine <[email-masked]> wrote:
>> will adapt the diagram style of Meadhbh and Carlo
>> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since
>> a good step forward
>> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We might
>> perhaps using policy URI's the way Meadhbh suggested
>> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A policy
>> I also think, like Meadhbh
>> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we

---

From: David W Levine <[email-masked]>
Date: Thu, 8 Oct 2009 13:31:12 -0400

[email-masked] wrote on 10/08/2009 12:45:56 PM:

[snip]
> information about agents to make policy decisions), rather than 
> propose anything. I think an attempt to define a global set of 
> characteristics about users that enable all policy decisions is 
> hopeless - cultures, laws, and individuals are too varied and rich. 
> That leaves pair-wise negotiation and/or trust networks, which IMHO 
> needs to happen *if* there are to be service-level distinctions for 
> most cases anyway.
> 
> What I forgot to say is: on the Web, as you move between sites you 
> accept various terms of service. Attempts to have your browser 
> automatically negotiate with sites over content have been extremely 
> limited - things like the defunct PICS (you tell your browser to 
> allow a third party site to rate the site you intend to visit), or 
> Google's features which block malware/phishing sites (and I believe 
> are used by current browsers as well when you just type a URL). Your
> user-agent (Web browser) does *not* have a built-in lawyer that 
> agrees to a TOS on your behalf, however. (I'm having flashbacks of 
> "Diamond Age" here - is that the right novel?)
> 
> In the VWRAP space, I don't believe your VW agent domain will be 
> capable of doing that in a totally generalized, automated way 
> either... so either it will have some a priori knowledge of the RD 
> via some manner (pair-wise negotiation, trust network, etc), defer 
> to the user to accept the TOS, or simply block access.
> 

> I'm leaning ever more strongly towards David's position that only 
> services should carry expressions of policy, not domains, because in
> the direction in which this discussion is heading there will be no 
> widespread interop at all.
> 
> I need to re-read Meadhbh's drafts to internalize the formal 
> terminology (yeah, my bad), but in my head a "domain" is a 
> deployment model for a set of conceptually related services, but 
> it's the service end-points that exist at the protocol level. We 
> talk about domains as clusters of conceptually related services as a
> crutch so we don't have to enumerate the specific services in each 
> conversation.
> 

I think this last is of the essence. Domains seem to be artifacts which
arise out of deployment patterns and how people may administrate deployed
systems. The clustering of services, the shared policies have very little 
to
do with protocol and a lot to do with how the endpoints implementing the
protocol are deployed. 

I am thinking that the overall model is very much that the protocols are 
the
mechanisms to ensure that the endpoints encoding common services work in 
the
same way, and the policies that specific endpoints apply will define 
bounds
on how the mechanisms are used. I would argue that what we need, therefore
(Once again sounding like a looping mp3) is to ensure we have the right
mechanisms defined in the protocols to permit the range of policies for 
which
we have use cases. 

I also think this ties to why I am pushing back a bit on how we are 
slinging
the phrase "domain" around. If domains actually are reflections of 
deployment patterns, then to a large extent, you need to describe
domains in a way that is closely coupled to specific deployments. If I
assume one deployment pattern and you another, and we each say "agent 
domain"
we end up talking at cross purposes, because our deployment assumptions 
create
domains which have different properties, which we paper over in the 
language 

- David Levine
~ Zha Ewwy

---

From: David W Levine <[email-masked]>
Date: Thu, 8 Oct 2009 13:43:43 -0400

This feels right. The leverage point the Agent Domain has on "protecting" 
its users is choosing whether or not
to send a user off to the region. If it has constraints, it is going to 
need assurances they are being met by
the region. These are policies on service endpoint requests 

I will then note, that the region may turn around and need assurances from 
services hosted by 
other service providers, for example, an asset service. It may have a 
local policy 
which says "I will only request asset fetching caps from asset servers 
which have a proof that
they legally mark adult content, and will not send me adult content" 

And.. now.. notice that the policy enforcement is local in both cases. The 
region protects itself
through a local choice to only accept content from "safe" sources. The 
Agent Domain
protect its users from "undesirable" content by ensuring that it checks 
destination for
conformance to its needs. before it hands users off to them. Neither 
service imposes 
behavior on other services, rather it only uses services which promise to 
meet its
standards. 

- David Levine
~ Zha Ewry

"Infinity Linden (Meadhbh Hamrick)" <[email-masked]> 
Sent by: [email-masked]
10/08/2009 01:26 PM

To
Morgaine <[email-masked]>
cc
"[email-masked]" <[email-masked]>, Magnus Zeisig <[email-masked]>
Subject
Re: [ogpx] Protocol for permitting policy decisions

-cheers
-meadhbh/infinity

the
> patterns which require much more flexibility.
since
>> It may also be an idea to permit caching of at least AD- and 
RD-parameters

---

From: Carlo Wood <[email-masked]>
Date: Fri, 9 Oct 2009 01:32:43 +0200

> negotiation during protocol exchanges.

I do not agree with this... for some policies this is good, but for
others it is not. Since we won't specify an exhausted list, but -hopefully-
treat everything abstractly, there still is the need for some abstract
list of policy negotiation in the protocol.

Example.

So far we concentrated on the decision "can this user teleport that region",
so allow me to use that case again:

* Problem: user can teleport from wherever to Region1 (R1) if both R1 and
  it's current Agent Service (A1) allow it.
* The Agent Service will initiate this, if it (already) thinks it's ok
  for the user to go to R1 (or would never ask R1).
  So, A1 policies ARE removed from the protocol, as you said.
* What remains are the policies of the region.
  If you eliminate those too from the protocol than the policy decision
  making becomes very unflexible. In effect, the right of the region
  to make also policy decisions would be at the mercy of the agent domain
  operators (ie, responsiveness) and very hard to change, certainly not
  frequently and not at all real-time.
  Surely some policies, like using md5 hashes for something, would be
  fine under such circumstances; but others, like FOR EXAMPLE (we don't
  KNOW what all else might pop up) banning certain users; or toggling
  'region has mature content' (some region might have adult shows between
  20:00 and 4:00, and PG-13 games between 12:00 and 17:00).

---

From: Carlo Wood <[email-masked]>
Date: Fri, 9 Oct 2009 01:39:18 +0200

> AD <-----------------------------(name, rez cap)-------------------------------

I'm ok with this extension, but also open to anyone suggesting it's too flexible,
in which case I guess we need to discuss (more) details.

Over all, I'd really like it if things go in basically this direction.

---

From: Carlo Wood <[email-masked]>
Date: Fri, 9 Oct 2009 01:56:38 +0200

On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote:
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2,
> because AD2 will be involved in region policy too.  It's symmetric with AD1.

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.
I'm also convinced that there is some misunderstanding involved here,
and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the truth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain'
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus
have different policies.

One user only uses a single authentication service at a time, every other
authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibility
open for a region to change some abstract policies (based on trusted information
from the agent service) more real-time. Here trust is needed in both directions:
the region must trust the agent service to answer it's questions correctly
and the agent service must trust the region not to fool it into allowing
users in that the agent service based on it's own policy doesn't want to
allow in.

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Fri, 9 Oct 2009 00:01:33 +0000

+1 on this approach.  

It makes sense to me and seems flexible enough to cover most all the scenarios we've discussed. This is the most complex case. In a simpler one there's no keys to negotiate over because they've been pre-agreed between AD and RD so it's simply the first and last flow.  All the exchanges in the middle are driven by constraints that need to be negotiated between the services involved.

Mike

---

From: Morgaine <[email-masked]>
Date: Fri, 9 Oct 2009 04:52:44 +0100

Magnus, I believe that we're fairly close on everything except the single
issue of "symmetry", because you still think that I'm talking about
deployment symmetry whereas I'm not at all, I'm talking about
*definition*symmetry.  However, I think I've found another way of
expressing it that
might come across better --- I'll focus on CODE.  Let's try this new
approach instead. :-)

Protocols aren't much use until they have been encoded in programs.  A
program that implements a given protocol fully is written to be able to
handle all the possible deployment patterns of that protocol.  This allows
the program to be used in many different situations to suit local
requirements.  Such a program is *NOT* written to suit *one
single*deployment pattern --- that would be inefficient.  Consequently
the code
that is written is *determined by the definition of the protocol and the
definition of the entities in the protocol*.  The code that is written is *
NOT* determined by the chosen *deployment*, I hope that's clear.

So now let's get back to ADs.  We don't want ADs to carry region policy, but
let's examine what happens if ADs are defined to do so.

 If ADs are defined to specify region policy, then a program that needs to
know about region policy would have to check the ADs --- there is no
escaping that.  *It would not be protocol-compliant if it did not check the
ADs.*  The deployment patterns in W1 and W2 (which could be completely
different) are of no relevance whatsoever in this --- the program would
still have to check for the presence of ADs in *both* worlds just in case
the ADs exist, and *all* those ADs that exist would have to be queried for
region policy because we've defined that region policy is carried by ADs.  *If
the program did not check both ADs then it could be missing part of the
region policy.* :-)

See what I mean by definition symmetry now?  However you define an AD, that
definition always applies to both ADs in a 2-world deployment if they
exist.  The definition can never apply only to one world --- it should be
clear that "*ADs carry region policies, but the region policies in my AD are
valid while the region policies in your AD will be ignored*" is completely
bogus. :-)  In protocol terms, this would be non-compliant because part of
the region policy would be missed.

As a result of this definitional symmetry, the only way we're going to be
able to avoid consulting AD2 is our little example scenario is by not
allowing ADs to express region policy at all, because if AD1 is allowed to
express region policy then AD2 is allowed to express it as well, and hence
the program *must try* to consult AD2 for its region policy, by definition
of AD.  It's very strong logic, and it has nothing to do with the chosen
deployments, because it applies *in case* AD2 exists.

Of course, as you pointed out, there are many more realistic deployments out
there, but this simple one is all that's needed to invalidate the idea that
AD1 can express region policy while AD2 can be present but ignored.  That
cannot happen unless the protocol explicitly defines asymmetric
relationships, which is not true in our case and cannot be true given that
W1 and W2 are peers.

That's all I wanted to describe in this particular reply.  I hope the point
was clearer this time. :-)

Morgaine.

==============================================

On Thu, Oct 8, 2009 at 3:41 PM, Magnus Zeisig <[email-masked]> wrote:

> Morgain, I believe we're not that far off from each other, even if I think
> the example you presented was not appropriate and I still can see no reason
> for your symmetry in AD/RD requests. The latter notion has already been
> commented upon by others in more detail. But like you, I also think it's
> reasonable to leave or generalize away from the thought of domains and
> rather use services as protocol endpoints. Regardless of if we talk about
> domains or services, I think the basic negotiation pattern will always be
> the same:
>
> Both client and server/service can be the agent or region domain,
> user/agent, authentication, presence, asset, inventory, simulation, voice or
> movie service, or any other domain or service you can think of, standalone
> or clustered in any combinations depending on technical issues, ownership
> and agreements.
>
> Policies in this case may refer both to things like data format (mesh
> format, image format) and data classification (adult, require IP
> agreements). The acceptance of policies, permitting the service performed,
> from both C and S, may be negotiated directly between C and S, or between
> servers/services connected to C and S respectively, negotiated at the time
> of service request and/or stored in some form of access, token or cap, at C
> and/or S respectively, or servers/services connected to them.
>
> If C and S are controlled by the same entity, that entity may use any way,
> including VWRAP, to negotiate and deliver the service, and the policy part
> may be left out from the negotiation, e.g. because the entity use the same
> policy for all services controlled.
>
> If C and S are controlled by different entities, those entities may use any
> way, including VWRAP, to negotiate and deliver the service, and the policy
> part may be left out from the negotiation, e.g. because the entities have an
> already established agreement (format agreement, domain of trust) or don't
> require one.
>
> To support a flexible new infrastructure with many different domains or
> services interacting in many different constellations, including interop
> between the "classical" virtual worlds of today, VWRAP should be able to
> treat any service request and/or policy negotiation the same or very
> similar, regardless of endpoints and endpoint types. The endpoints will
> mutually decide if to use VWRAP and to which extent. VWRAP should however be
> an attractive enough way to handle the communication to be a first hand
> choice, both between clients and servers/services of the same as well as
> different entities. One advantage of using VWRAP will then be that
> outsourcing, exchange or addition of services will be easy, since basically
> just addresses of servers/services will need to be changed and transfer of
> old data to the new services be performed.
>
> I know that some of the things above have already been stated on the list,
> but I'm repeating them just for the clarity of argumentation.
>
> Best regards,
>
> Magnus
>
>
> When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not at all
>  the actual deployment scenario that any of us expects to see.  It's just
> the smallest case that allows us to say something concrete about the
> problems with the original OGP design when extrapolated to the multi-world
> deployment scenario.  So please don't attribute any narrow vision in this
> scenario to me --- I'm fully aware that it's artificial and is going almost
> nowhere.  I'm merely doing a smallest-possible scenario analysis.
>
> https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no
> point describing a massively complex deployment example when a simpler one
>        No, you are still stuck in the concept of one virtual world equals
> one AD plus one RD, even if you say you recognize a future more complex
> service pattern. VW=AD+RD does not have to be the case with VWRAP.
>
>
>
> example, there need to be (i) asset service contributions from both worlds
> The simpler cases, such as no AD2 exists, or only W1 asset services are
> used in W2, can be handled by the original OGP design, so they wouldn't have
> Obviously multi-world deployment scenarios such as we expect to be common
> in the metaverse are going to have much more complex deployment patterns
>        If it _happens_ to be the case and the entity controlling AD2 and
> RD2 wants to enforce AD2 policy for those visiting RD2, then they can move,
> duplicate or mirror the enforcement of that policy from AD2 to RD2, which
> they can do without problems as long as they control both. If they don't
> control both, then it's entirely up to the entity controlling RD2 if they
> for some reason want to enforce the policy of the entity controlling AD2. So
> I see no reason whatsoever why symmetry is required.
>
>
>
>
> Ah, here you've simply misunderstood me:  you think I'm talking about
> deployment symmetry, but I'm not.  I'm talking about definition symmetry:
>  if ADs are defined to be able to control region policies, then by symmetry
> that applies to all ADs.  It wouldn't make sense to say "ADs are defined to
> carry region policy, but this only applies to our ADs and not to yours."
>  ;-)  That's what I mean by this applying symmetrically.
>
>
> Sure, but someone has to code this stuff.  It's not helpful to say
> "Anything can be done anywhere", because that would mean that the protocol
> would at every decision point have to gather policy contributions from all
> possible endpoints.  It can be done this way of course, but if a simpler
> design suffices then a more compex one may not be a good idea.
>
>        But, like you, I am totally in favor of letting the entity
> controlling the destination RD decide policy once the agent is there.
> However, if the agent's own AD for some reason wants to stop the agent from
> going there, then I think it should have the possibility to do so. In all
> honesty, I don't think an AD imposing undue restrictions on where people are
> allowed to go or what they are allowed to do there will survive for long
> though, once competition is in place. You may have to start out fresh, with
> a new AD, without the assets and inventory connected to the old AD, but I
> think most people are willing to take that step if they feel their freedom
> is too limited.
>
>
>
> Well in my case I'm not merely "in favour" of region policy control by
>        No, you are still stuck in the concept of one virtual world equals
> one AD plus one RD, even if you say you recognize a future more complex
> service pattern. VW=AD+RD does not have to be the case with VWRAP. If it
> _happens_ to be the case and the entity controlling AD2 and RD2 wants to
> enforce AD2 policy for those visiting RD2, then they can move, duplicate or
> mirror the enforcement of that policy from AD2 to RD2, which they can do
>        But, like you, I am totally in favor of letting the entity
> controlling the destination RD decide policy once the agent is there.
> However, if the agent's own AD for some reason wants to stop the agent from
> going there, then I think it should have the possibility to do so. In all
> honesty, I don't think an AD imposing undue restrictions on where people are
> allowed to go or what they are allowed to do there will survive for long
> though, once competition is in place. You may have to start out fresh, with
> a new AD, without the assets and inventory connected to the old AD, but I
> think most people are willing to take that step if they feel their freedom
> is too limited.
>
>
>        Best regards,
>
>        Magnus
>
>
>        If ADs are involved in region policy, then in the multi-world
> deployment pattern, AD2 will have to be consulted when agent A1 teleports
> from RD1 to RD2, because AD2 will be involved in region policy too.  It's
> symmetric with AD1.
>
>        This is what Joshua wanted to avoid, and it can only be avoided by
> not giving ADs policy control over regions, otherwise symmetry requires that
> AD2 be consulted as well.
>
>        It's this kind of problem that reinforces what David's been saying
> about the right mess we currently have when talking about domains
> determining policy.  The AD/RD split was reasonably adequate when OGP was
> only extending a single world with policy-free regions, but it is
> insufficient to do a good job once we get into multi-world deployments with
> more complex service and policy patterns which require much more
> flexibility.
>
>
>        Morgaine.
>
>
>
>
>               I am strongly in favour of leaving policy descisions to the
> RD, but since there seems to be a need for at least some AD managers to be
> able to make policy decisions as well, I guess the protocol handshake need
> even more flexibility than the versions scetched on by Meadhbh, Carlo and me
> so far. I will adapt the diagram style of Meadhbh and Carlo (
>               I may be paranoid, but I still prefer agent domains to be
> allowed, but not forced by protocol, to reduce the dissemination of
> information about their clients as far as possible, and there Carlo's AND
> version in the response is a good step forward (
>               In this example, RD might have refused giving the required
> range for agentvalue2, either because it technically doesn't support that
> kind of negotiation or because of policy, in either case of which the rez
> cap would have failed. It might on the other hand instead already from the
> beginning have supplied the required ranges instead of asking for the actual
> value. I think it would be good if the protocol would enable either of these
> cases for maximum flexibility.
>

---

From: Morgaine <[email-masked]>
Date: Fri, 9 Oct 2009 05:10:48 +0100

> I'm pretty sure nobody on this list wants AD2 to be involved in anyway.

Yes, I think that everybody agrees with this, which is why I'm making sure
that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to
everyone that *if we don't want AD2 to be consulted, then AD1 cannot be
allowed to express region policy*.  *AT ALL.  EVER.*  UNDER ANY
CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be
consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give AD1
the power to set region policy over RD2.  If that happens, then we're back
to consulting AD2, no alternative, because W2 is not in any way inferior to
W1.

It's a crucial point, because it establishes *a limit to the power of an AD*.
Think of it as a mini Constitution. ;-)

Morgaine.

===================================

---

From: David W Levine <[email-masked]>
Date: Fri, 9 Oct 2009 00:16:44 -0400

I actually kind of defy anyone to impose a policy on a separately hosted 
remote service. Policy is enforced locally, Attempting to make other 
software components obey a
policy you have is pretty much a non starter. You can request they do 
things, and you can insist they exhibit certain properties when choosing 
to interact with them, but
you get no say in their workings.  (Yes, there are systems with remote 
policy execution engines and such, but they still don't impose the 
policies on the services which use
them, the services chose to invoke them)

- David
~ Zha

10/09/2009 12:10 AM

To

Subject

Morgaine,

I am highlighting this point of logic very strongly so that it is clear to 
everyone that if we don't want AD2 to be consulted, then AD1 cannot be 
allowed to express region policy.  AT ALL.  EVER.  UNDER ANY 
CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to 
be consulted, :-)

I will however be referring back to this point if someone tries to give 
AD1 the power to set region policy over RD2.  If that happens, then we're 
back to consulting AD2, no alternative, because W2 is not in any way 
inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD
.  Think of it as a mini Constitution. ;-)

Morgaine.

Morgaine,

It makes no sense whatsoever to group A's with R's for the sake of 
understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and 
ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the 
possibility
open for a region to change some abstract policies (based on trusted 
information
from the agent service) more real-time. Here trust is needed in both 
directions:
the region must trust the agent service to answer it's questions correctly
and the agent service must trust the region not to fool it into allowing
users in that the agent service based on it's own policy doesn't want to
allow in.

---

From: Morgaine <[email-masked]>
Date: Fri, 9 Oct 2009 05:28:29 +0100

On Thu, Oct 8, 2009 at 5:45 PM, Joshua Bell <[email-masked]> wrote:
On Wed, Oct 7, 2009 at 8:34 PM, Morgaine <[email-masked]>wrote:
Are we trying to create an interop protocol here, or a protocol for
preventing interop?

> service-level distinctions for most cases anyway.

Don't worry, I was slightly chuckling as I wrote that --- it was more
despondancy than objection. ;-)   I do of course fully agree that everyone
should be able to choose whatever policy they want.  The only thing that
worries me is that we are spending an inordinate amount of time examining
how to deny interop, and almost no time on how to achieve it.

I hope that this is a passing phase, and that we're about to embark on
detailed discussion about how avatars, assets, objects and everything else
actually move between regions spread across many worlds, as this is the end
goal.  Blocking interop has already been achieved *perfectly*, by not having
the worlds connected.  It's time to look at the opposite. :-)

Morgaine.

========================================

---

From: Morgaine <[email-masked]>
Date: Fri, 9 Oct 2009 05:43:00 +0100

A big +1, David!

And yet, despite knowing that non-local policy enforcement is a fiction
because it's *services* that express policy, I still see people attached to
the delusion that a safe, protected environment will be achieved through
some kind of transitive or viral contagion of local policy to create a
widespread non-local policy, as if domains spread policy by contact.

The implication permeates this thread, and we're going to have to examine it
in detail to see who is right.

Morgaine.

=====================================

On Fri, Oct 9, 2009 at 5:16 AM, David W Levine <[email-masked]> wrote:

> things, and you can insist they exhibit certain properties when choosing to
> interact with them, but
> policy execution engines and such, but they still don't impose the policies
> on the services which use
>  *Morgaine <[email-masked]>*
> On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <[email-masked]*<[email-masked]>>
> wrote:
>
> Morgaine,
>
> It's a crucial point, because it establishes *a limit to the power of an
> AD*.  Think of it as a mini Constitution. ;-)
>
>
> Morgaine.
>
>
>
>
>
>
>
>
> On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <[email-masked]*<[email-masked]>>
> wrote:
> Carlo Wood <[email-masked]* <[email-masked]>>

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 9 Oct 2009 10:48:52 +0200

Yes, this all sounds good!-Vaughn

---

From: Magnus Zeisig <[email-masked]>
Date: Fri, 9 Oct 2009 12:00:48 +0200

Morgaine, I think I understood your meaning with the first example, and I also think I do it with the second example. And I still see no requirement for your symmetry, or whatever you prefer to call it. Let's recapitulate so people don't need to browse back. An agent using AD1 wants to teleport (TP) from VW1, consisting of AD1 and RD1, to VW2, consisting of AD2 and RD2.

For the TP to happen, AD1 needs to agree to try the TP because it's used by the agent. RD2 needs to accept the TP because it will handle the agent's presence. RD1 should have no say since it will not be used by or handle the agent. AD2 should have no say since it will not be used by or handle the agent. That's my idea of perfect symmetry, but...

Assume that AD1 or RD2 for the reason of "symmetry", or something else, wants AD2 to have a say about the TP. Since AD1 and RD2 are the only entities involved with the agent after TP, they are the only ones who should be able to make that call, except for the agent itself, e.g. if it would like AD2 to act Net-Nanny. Then I believe this is how it should work:

Case 1: Agent (ID1) wants to consult AD2 about TP:

ID1 --(ID1, TP RD2?)-> AD2
AD2 --(ID, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, <RD2value1, RD2value2>)-> AD2
AD2 --(ID1, <RD2values OK>, TP RD2 OK)-> ID1
ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RD2values OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

Case 2: AD1 wants to consult AD2 about TP:

ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID, TP RD2?)-> AD2
AD2 --(ID, <AD1key1?, AD1key2?, IDkey1 range?, IDkey2 range?>)-> AD1
AD1 --(ID, <AD1value1, AD1value2, IDkeys OK>)-> AD2
AD2 --(ID, <AD1values OK>, TP RD2 OK)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

Case 3: RD2 wants to consult AD2 about TP:

ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, rez cap?)-> AD2
AD2 --(ID, <ADkey1?, ADkey2?, IDkey1 range?, IDkey2 range?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 range?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)-> RD2
RD2 --(ID, <ADvalue1, ADvalue2, IDkeys OK>)-> AD2
AD2 --(ID, <ADvalues OK>, rez cap OK)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1

The calling domain or service should never be forced to call more than one (the receiving) domain or service, but it could choose to do so (Cases 1 and 2). What happens behind the endpoint it sees is really none of its business (Case 3).
In cases 2 and 3, much of the extra hand-shaking could be replaced by pre-arranged agreements or duplication of policies, and may also require pre-arranged domains of trust.
The VWRAP protocol may be used for the consulting as well, if it's assumed to have the generalized form suggested in my previous post (http://www.ietf.org/mail-archive/web/ogpx/current/msg00538.html).
The consulting could be made the same way regardless of if the domains or services are controlled by the same entity or not.
Actually, AD2 could be AD3 or service4762, without any administrative connection whatsoever with AD1, RD1 or RD2 (or AD2, if it still exists and forms VW2 with RD2).
Note that the consulting domain or service doesn't have to reveal the identity of the calling agent, domain or service to the consulted domain or service.

Best regards,

Magnus

- -----Ursprungligt meddelande-----
Från: Morgaine [mailto:[email-masked]]
Skickat: den 9 oktober 2009 05:53
Till: Magnus Zeisig
Kopia: [email-masked]
Ämne: Re: [ogpx] Protocol for permitting policy decisions

Magnus, I believe that we're fairly close on everything except the single issue of "symmetry", because you still think that I'm talking about deployment symmetry whereas I'm not at all, I'm talking about definition symmetry.  However, I think I've found another way of expressing it that might come across better --- I'll focus on CODE.  Let's try this new approach instead. :-)

Protocols aren't much use until they have been encoded in programs.  A program that implements a given protocol fully is written to be able to handle all the possible deployment patterns of that protocol.  This allows the program to be used in many different situations to suit local requirements.  Such a program is NOT written to suit one single deployment pattern --- that would be inefficient.  Consequently the code that is written is determined by the definition of the protocol and the definition of the entities in the protocol.  The code that is written is NOT determined by the chosen deployment, I hope that's clear.

So now let's get back to ADs.  We don't want ADs to carry region policy, but let's examine what happens if ADs are defined to do so.

 If ADs are defined to specify region policy, then a program that needs to know about region policy would have to check the ADs --- there is no escaping that.  It would not be protocol-compliant if it did not check the ADs.  The deployment patterns in W1 and W2 (which could be completely different) are of no relevance whatsoever in this --- the program would still have to check for the presence of ADs in both worlds just in case the ADs exist, and all those ADs that exist would have to be queried for region policy because we've defined that region policy is carried by ADs.  If the program did not check both ADs then it could be missing part of the region policy. :-)

See what I mean by definition symmetry now?  However you define an AD, that definition always applies to both ADs in a 2-world deployment if they exist.  The definition can never apply only to one world --- it should be clear that "ADs carry region policies, but the region policies in my AD are valid while the region policies in your AD will be ignored" is completely bogus. :-)  In protocol terms, this would be non-compliant because part of the region policy would be missed.

As a result of this definitional symmetry, the only way we're going to be able to avoid consulting AD2 is our little example scenario is by not allowing ADs to express region policy at all, because if AD1 is allowed to express region policy then AD2 is allowed to express it as well, and hence the program must try to consult AD2 for its region policy, by definition of AD.  It's very strong logic, and it has nothing to do with the chosen deployments, because it applies in case AD2 exists.

Of course, as you pointed out, there are many more realistic deployments out there, but this simple one is all that's needed to invalidate the idea that AD1 can express region policy while AD2 can be present but ignored.  That cannot happen unless the protocol explicitly defines asymmetric relationships, which is not true in our case and cannot be true given that W1 and W2 are peers.

That's all I wanted to describe in this particular reply.  I hope the point was clearer this time. :-)

Morgaine.

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 9 Oct 2009 12:51:20 +0200

Maybe mostly out of protocol, but depicting the situation very well!-Vaughn

On Thu, Oct 8, 2009 at 12:38 PM, Magnus Zeisig <[email-masked]> wrote:

> In the future I think we will have a VWRAP metaverse similar to how the web
> works today. The VWRAP protocol will enable both private persons and major
> organizations to set up and interop, to the degree each entity wants, their
> own corner of the virtual world with the rest of that world. Just like on
> the web, we will see entities running "intra-metaverses", totally shut off
> or only to a limited degree open to the public. We will probably also see
> attempts by some major entities, just like e.g. Microsoft Network, to set
> their own standards and believe they are big enough to force others to adapt
> to those standards, and we will probably, just as was the case with
> Microsoft Network, see those attempts fail.
>
> In the beginning, there will probably be a few major players with a head
> starts and server parks, and a multitude of small players, running their
> pieces of the virtual world using e.g. OpenSimulator, on their desktop or
> laptop computers. Many of the small players will probably have the very
> simple policy of "If you want to connect, welcome, regardless of your
> credentials, but if you misbehave I will kick you out." In time, some of
> those small players will grow because they serve interesting content or
> create social networks with many users/visitors. Most of them will probably
> see a need to develop more strict policies to enable administration of their
> services at all, so they don't have to spend all day kicking abusers
> returning time after time with new identities, disrupting the experience for
> other users.
>
> Those service and domain managers requesting some kind of trust domain to
> allow others using or connecting to their services and domains will either
> cut themselves off from all those small players running their domains or
> services home in their kitchen or cupboard, ease up on their demands for
> domains of trust, or simplify the procedure so that the necessary domain of
> trust can be established via electronic signatures on the first connection.
> If they choose to remain cut off from the rest of the metaverse, they will
> probably soon be forgotten islands in the sea of tens or hundreds of
> thousands minor domains and services interoping more freely.
>
> The point is that the VWRAP protocol will not proscribe how you should run
> your service, open or as a walled garden, small or big. It will permit you
> to interop to the degree you chose yourself, not forcing you to interop any
> more or less than that. Other factors, like international law, national
> legislation, ISP TOS, organization policies and such, may force you to set
> limitations or raise requirements on with who and how you interop, but VWRAP
> should offer you the tool to do so, regardless of if you want, or are
> forced, to run a strictly regulated walled garden alone or including a few
> trusted peers, by supporting the communication needed for
> policy-enforcement, or run a no-holds-barred free-for-everyone operation, by
> not requiring the use of any policy-support whatsoever.
>
> Best regards,
>
> Magnus
>
>
> Från: Morgaine [mailto:[email-masked]<[email-masked]>]
>
> wsBVAwUBSs3BOO5MlU9XyaiSAQj2yQgAjrwKp/YhSe+o8klsPg/LV+G6XS1LaBh9
> 2kEc31liqvttvOHYoRdhrCMT2Yh5F0PKjb/daDqK/3duTgTbz277sZS+P5xnfzxr
> gsJN4Y//kuKcdmc3rQTaYafo9azl4JslPKNiQ2lSTcKDwAA1jn5hamBuiP1TdxQD
> 1GQH4zhOPvEkfPJKCW4yGJdyp30dYdYFv6Ka/Rl5vAesPXStmpoBQ6x9fxtSpvVT
> VV6YMJyEUYCnU+1voGO/rCJt1AKNJCOUnCXx0N+a5Xrix0oW7azx3xw6G6/RCuVv
> GY+lweiE/bqfTb4Qr8/edV4Ffey2fo21plKABQ5worpGKL9/kfg2iw==
> =1YBE

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 9 Oct 2009 06:39:23 -0700

On Thu, Oct 8, 2009 at 21:16, David W Levine <[email-masked]> wrote:

> policy you have is pretty much a non starter.

+1. i don't know how we got off on talking about distributed policy, but
yes, in my view of the world, "policy" describes the decisions that a
domain's authorities have made for a particular entity accessing resources
via service interfaces, not the description of decisions that one domain's
authority wants services in another domain to make.

> You can request they do things, and you can insist they exhibit certain
> properties when choosing to interact with them, but

---

From: Morgaine <[email-masked]>
Date: Fri, 9 Oct 2009 15:31:10 +0100

On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig <[email-masked]> wrote:

>
> Morgaine, I think I understood your meaning with the first example, and I
> also think I do it with the second example.
>

Cool.  :-)   I'll assume the point's taken then.  If any doubt seems to
remain then we can beat it into submission in private mails. :-)

Morgaine.

On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig <[email-masked]> wrote:

> Morgaine, I think I understood your meaning with the first example, and I
> also think I do it with the second example. And I still see no requirement
> for your symmetry, or whatever you prefer to call it. Let's recapitulate so
> people don't need to browse back. An agent using AD1 wants to teleport (TP)
> from VW1, consisting of AD1 and RD1, to VW2, consisting of AD2 and RD2.
>
> For the TP to happen, AD1 needs to agree to try the TP because it's used by
> the agent. RD2 needs to accept the TP because it will handle the agent's
> presence. RD1 should have no say since it will not be used by or handle the
> agent. AD2 should have no say since it will not be used by or handle the
> agent. That's my idea of perfect symmetry, but...
>
> Assume that AD1 or RD2 for the reason of "symmetry", or something else,
> wants AD2 to have a say about the TP. Since AD1 and RD2 are the only
> entities involved with the agent after TP, they are the only ones who should
> be able to make that call, except for the agent itself, e.g. if it would
> like AD2 to act Net-Nanny. Then I believe this is how it should work.
>
> The calling domain or service should never be forced to call more than one
> (the receiving) domain or service, but it could choose to do so (Cases 1 and
> 2). What happens behind the endpoint it sees is really none of its business
> (Case 3).
> In cases 2 and 3, much of the extra hand-shaking could be replaced by
> pre-arranged agreements or duplication of policies, and may also require
> pre-arranged domains of trust.
> The VWRAP protocol may be used for the consulting as well, if it's assumed
> to have the generalized form suggested in my previous post (
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00538.html).
> The consulting could be made the same way regardless of if the domains or
> services are controlled by the same entity or not.
> Actually, AD2 could be AD3 or service4762, without any administrative
> connection whatsoever with AD1, RD1 or RD2 (or AD2, if it still exists and
> forms VW2 with RD2).
> Note that the consulting domain or service doesn't have to reveal the
> identity of the calling agent, domain or service to the consulted domain or
> service.
>
> Best regards,
>
> Magnus
>
>
> deployment symmetry whereas I'm not at all, I'm talking about definition
> symmetry.  However, I think I've found another way of expressing it that
> requirements.  Such a program is NOT written to suit one single deployment
> pattern --- that would be inefficient.  Consequently the code that is
> written is determined by the definition of the protocol and the definition
> of the entities in the protocol.  The code that is written is NOT determined
> by the chosen deployment, I hope that's clear.
>
> So now let's get back to ADs.  We don't want ADs to carry region policy,
> but let's examine what happens if ADs are defined to do so.
>
> escaping that.  It would not be protocol-compliant if it did not check the
> ADs.  The deployment patterns in W1 and W2 (which could be completely
> still have to check for the presence of ADs in both worlds just in case the
> ADs exist, and all those ADs that exist would have to be queried for region
> policy because we've defined that region policy is carried by ADs.  If the
> program did not check both ADs then it could be missing part of the region
> policy. :-)
>
> clear that "ADs carry region policies, but the region policies in my AD are
> valid while the region policies in your AD will be ignored" is completely
> the program must try to consult AD2 for its region policy, by definition of
> AD.  It's very strong logic, and it has nothing to do with the chosen
> deployments, because it applies in case AD2 exists.
>
> Of course, as you pointed out, there are many more realistic deployments
> out there, but this simple one is all that's needed to invalidate the idea
> that AD1 can express region policy while AD2 can be present but ignored.
> That cannot happen unless the protocol explicitly defines asymmetric
> wsBVAwUBSs8FtO5MlU9XyaiSAQg8HAf8DHf30qo45JVvrYJ6Vv2essw+MJ1Rbkjk
> BA34EazFEnqoR3krpD5ZOJrYVuG7HbUqBOz8Rl7p4l9lWZBkeeWnpeAk40gCHxNP
> 8fE0cCnDT+n5XShzetNPo7H/VskJ3/niXWMrmI295DwErCKInzelkjUaI/9TgiSi
> DOIwoPMQDPzrn3YM6vvBtDODjoTkajNRP+D5++XDE5gyZ3EJacl4KCOMqkz5ai1B
> XUW5osTLTaDiFDF69QtJIwdl8/BTzN1OsUlBCFC+XlaWK2TgSnXMm1DQ8EWk3iHQ
> DJ0VlRWpJJkmQVWZMsrGivjZi2WaeI3YlsxxCTbAeOaM7Jqvc0EPiw==
> =KZF3

---

From: Vaughn Deluca <[email-masked]>
Date: Mon, 12 Oct 2009 21:44:56 +0200

David wrote

>I would suggest that one good way forward on this is to develop a set of
policy use cases
>to drive our analysis of the protocol and specifications, and then look at
whether we can
>reasonably manage these use cases."

I agree, and the obvious place to start is
http://tools.ietf.org/html/draft-levine-ogp-layering-00 were David provides
a number of deployment patterns:

>5.  Second Life Agent Domain / Region Domain Split
>6.  Standalone OpenSim Region model
>7.  OpenSim OGP + Asset reflector + Agent Service
>8.  OpenSim UGAIM grid model
>9.  Hypergrid
>10. Hypergrid and Cable Beach
>11. Multi-hosted asset deployment
>12. Factored Service Models

I will try to extend pattern 5, and first see how far it can be applied to a
TP between two Regions in different Region domains. I will work towards what
 Morgaine called the tourist model --Morgaine, if i am misrepresenting your
idea please jump in and correct were needed :)

Some features mentioned in pattern 5 are:

(1) The agent domain acts as a unitary focus for all services associated
with the agent.
(2) When accessing other services hosted by a deployer other than the hoster
of the agent domain, the agent domain acts as the trust source, managing the
agent (and user's) access to other regions.
(3) [not considered yet to keep things simple]

I think that these two features can also be used in the tourist model. To
keep things simple at first, lets leave out assets for now, and consentrate
on TP. Also I find it easier to analyse the needs and constrains when using
a real protocol example. The protocol steps for TP have been described in
http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_5. The high level
description in this document is this:

"In all cases, the sequence of resource invocations follows the same form.
First, the Viewer invokes Place Avatar on the agent's Agent Domain. While
processing Place Avatar, Agent Domain asks the destination region if the
avatar can be placed by requesting and invoking the Request Rez Avatar
resource. If the agent is already connected to a region, in the previous
Teleport, the Agent Domain has already stored away the Derez Avatar
capability for that agent.
The Agent Domain passes the Rez Avatar capability to the (stored away) Derez
Avatar capability, asking the current region to transfer the avatar to its
destination. The current region in turn transfers the avatar to the
destination by POST'ing to the Rez Avatar resource. The response to Rez
Avatar is propagated all the way back to the Agent Domain, which passes the
results overlayed with the response from Request Rez Avatar back to the
Viewer. Finally, the Viewer establishes communication with destination
region to begin simulation. "

The Naming convention in the rest of this text is what we used in several
post now: D for domain and S for service, A for agent, R for region.
 Services from different administrative domains get different numerical
suffixes (e.g AD1, AD2). In addition instances of a particular  servicetype
within some domain could be given a second  numerical suffix that identifies
the particular instance  (e.g. RS1.1, RS1.2 and RS1.3 for three region
services belonging to RD1.

The TP-Draft_5 high level description starts with an agent logged in into
AD1, with a rezzed avatar in RS1.1 and a Derez cap for the avatar stored by
AD1.
I have numbered the steps for easy reference and write all calls from left
to right.

(1) Viewer---("place avatar" request for RS2.1)---> AD1
Note that AD1 is is domain, not a service, so i we might need to tighten the
language here a bit also, but for now i will let that go.

(2) AD1 can checks (behind its interface) if its policy will allow this TP,
this is outside the protocol.
If AD1 allows the TP it asks RS2.1 for a "rez avatar cap":

(3) AD1---( "Rez avatar cap" request )---> RS2.1

(4) In this stage RS2.1 can apply its own policy and/or (behind its own
interface) consult RD2 to check global domain policy, as suggested by David
and after that by me, elsewhere in the discussion.  RS2.1 might also want
extra info about agent_ID@AD1. How to do this, and how wise it is has been
the subject of much of the recent discussion.
I liked the multi-message handshake suggestion of Magnus and Infinity, for
example:

(5) RS2.1---(X, age > X? cap)---> AD1
If AD1 does not want to give this information or cannot do so, it does not
use  the cap and reports a failure back to the viewer. Otherwise it uses the
cap:

(6) AD1 ---(POST)----> age > X? cap

If RS2.1 now wants to allow the TP, the  Rez avatar cap is returned (as well
as some other caps that are a bit out of scope here)

(7) RS2.1---( Rez avatar cap)---> AD1

(8) AD1---(Rez avatar cap) ---> Derez avatar cap
The stored Derez avatar cap is a URI pointing to the current region of the
avatar, in this case RS1.1

(9) RS1.1---(POST)---> Rez avatar cap
The Rez avatar cap is un URI pointing to the destination region of the
avatar, in this case RS2.1

(10) RS2.1---( Rez avatar result)---> RS1.1

(11) RS1.1---(Rez avatar result)---> AD1

(12) AD1---(Place avatar result, Rez avatar result)--->  viewer
The viewer can now contact the region.

As far as I can see this fits the tourist model , as well as the deployment
pattern under point 5 in the layering document. (ignoring assets for the
moment).  Am i right? or did i overlook something?

On Thu, Oct 8, 2009 at 3:57 PM, David W Levine <[email-masked]> wrote:

> policy decisions are local" This doesn't mean they don't represent a way of
> solving a globally distributed use case, but
> it highlights the fact the one software element, hosted behind and endpoint
> can't impose behavior on another such endpoint. In the case of how a service
> in an Agent Domain interacts with the services in a region domain, the Agent
> Domain is limited to controlling what *it* does. So, in the case of an agent
> domain which has the policy of not permitting its users to be exposed to
> "mature" content. The agent domain, however, doesn't perform the delivery of
> content from the region. It handles authentication, and global presence
> management, and possibly inventory management, but, it doesn't control what
> happens in the region. (In fact, in the current model, it doesn't even see
> the traffic, but seeing it wouldn't help)
>
> information the region exports, and deciding whether or not this is a region
> where it is safe for its agents to travel. The region, of course, can say
> whatever it wants. So.. if the Agent Domain wants certainty, it needs for
> the
> region to not only export information it can use to make this decision, but
> to export it in a way that gives the agent domain increased certainty.
> description level, most of what needs to happen to support this model is to
> make sure we know where services expose meta-data and how it is formatted.
> The protocol need not focus on what the meta-data represents, but that it is
> there and available for supporting policy decisions.
>
> focus needs to be having the use cases which enable us to make sure we *can*
> export and understand
> language permitting various services to reason about the policies governing
> a given service they wish to interact with. But.. That's not needed to make
> the protocol work. I view this as a good thing, since it is a decidedly non
> trivial problem to solve.
>
> consist of checking for meta-data signed using existing PKI standards (x.509
>  is the obvious one) and making decisions based on this meta-data.
>
> - David W. Levine
> ~ Zha Ewry
>
>
>
>
>  *Carlo Wood <[email-masked]>*
> Infinity Linden <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Magnus Zeisig <
> [email-masked]>  Subject

---

From: Carlo Wood <[email-masked]>
Date: Thu, 15 Oct 2009 12:54:30 +0200

> avatar, in this case RS1.1

Why is this step needed?

> The Rez avatar cap is un URI pointing to the destination region of the avatar,
> in this case RS2.1

Why is RS1.1 involved in the TP to RS2.1?
This seems to mean that:
a) RS1.1 can stop a successful TP away from RS1.1 to RS2.1
b) RS1.1 learns about where an avatar TPs away to (privacy issue)

> (11) RS1.1---(Rez avatar result)---> AD1

Same thing; there is no need for RS1.1 to be 'in between' this, is there?

---

From: David W Levine <[email-masked]>
Date: Thu, 15 Oct 2009 12:58:55 -0400

Region 1 (the source) holds the current state of the avatar. Running 
scripts in attachments, in particular. Without the source region 
participating, you end up having no way to
retrieve that state, nor a way to know when that region can stop 
simulating the avatar.  Now.. You could go R1->AD->R2 which would obviate 
the privacy concern, but you end up
with a pass through the "Not present in any region" state which might be 
disconcerting. (You also add at least one set of transactions to the 
dance, which, again isn't too bad) 
For edge crossings and TPs within a single "domain" that seems awfully 
expensive. 

- David
~ Zha

10/15/2009 06:54 AM

To
Vaughn Deluca <[email-masked]>
cc
David W Levine/Watson/IBM@IBMUS, Infinity Linden <[email-masked]>, 
Meadhbh Hamrick <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>, Magnus 
Zeisig <[email-masked]>
Subject
Re: [ogpx] Protocol for permitting policy decisions

Why is this step needed?

> The Rez avatar cap is un URI pointing to the destination region of the 
avatar,

---

From: Morgaine <[email-masked]>
Date: Fri, 16 Oct 2009 07:35:59 +0100

There are two cases here:

   1. When the source R1 and destination R2 regions belong to the same
   administering authority, then it is a reasonable optimization for serialized
   agent data to be transferred directly from R1 to R2.
   2. In contrast, when they belong to different administrations then there
   is a privacy concern (as various people have mentioned), since it is no
   business of R1's to know that the agent is going to R2 nor any business of
   R2's to know that the agent came from R1.

As long as we consider the direct R1->R2 shortcut to be a *local* *
optimization*, we're fine, since both privacy and efficiency can be
satisfied in the distinct cases where each one is appropriate.  I think that
this is a reasonable implementation note that we could add to the protocol
specification.

What the teleport specification must *not* do however is to mandate a direct
R1-R2 network connection, since that would deny case 2).

Morgaine.

On Thu, Oct 15, 2009 at 5:58 PM, David W Levine <[email-masked]> wrote:

> retrieve that state, nor a way to know when that region can stop simulating
> the avatar.  Now.. You could go R1->AD->R2 which would obviate the privacy
> concern, but you end up
> disconcerting. (You also add at least one set of transactions to the dance,
> which, again isn't too bad)
> Meadhbh Hamrick <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Magnus

---

From: Vaughn Deluca <[email-masked]>
Date: Fri, 16 Oct 2009 09:07:03 +0200

I  agree with this conceptual split, yet i would like to stick to the more
precise terminology I outlined above.R1 and R2 are *by definition* in
different domains.
The case you mention in 1. is a  R1.1 -> R1.2 transfer.

In addition it can be argued that it should be left to the AD to decide how
far its wants to optimise.
As long as the protocol *allows* a region transfer via the AD rather than
requiring the direct R1->R2 connection everybody can be satisfied. Its left
up to the end users to pick an agent domain that fits their needs for
privacy.

-Vaughn

On Fri, Oct 16, 2009 at 8:35 AM, Morgaine <[email-masked]>wrote:

>    2. In contrast, when they belong to different administrations then
>    there is a privacy concern (as various people have mentioned), since it is
>    no business of R1's to know that the agent is going to R2 nor any business
>    of R2's to know that the agent came from R1.
>
>
> What the teleport specification must *not* do however is to mandate a
> direct R1-R2 network connection, since that would deny case 2).
>
>
> Morgaine.
>
>
>
>
>