Re: [ogpx] Protocol for permitting policy decisions

[David W Levine <[e-mail]>]

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)" <[e-mail]> 
Sent by: [e-mail]
10/08/2009 01:26 PM

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






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 <[e-mail]> 
wrote:
> 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 <[e-mail]> 
wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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:[e-mail]]
>> Skickat: den 7 oktober 2009 22:36
>> Till: Infinity Linden
>> Kopia: Magnus Zeisig; [e-mail]
>> Ämne: Re: [ogpx] Protocol for permitting policy decisions
>>
>> On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote:
>> > option 3: multi-message handshake
>> >
>> > AD --------------- (name) -------------> RD
>> > AD <-------- (X, age > X? cap) --------- RD
>> >
>> > AD ------------------------------------> RD (age > X? cap)
>> > 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.
>>
>> - --
>> Carlo Wood <[e-mail]>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 9.8.3 (Build 4028)
>> Charset: utf-8
>>
>> wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL
>> JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/
>> cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ
>> RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm
>> tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd
>> 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w==
>> =2NSu
>> -----END PGP SIGNATURE-----
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx