Subject: [ogpx] The Role of Policy and Processing Expectations in Protocol Development

From: Infinity Linden <[email-masked]>
Date: Sat, 22 Aug 2009 13:00:03 -0700

So I too recently wrote a long, rambling narrative in response to
Carlo's recent message where I tried to concisely explain how we got
to where we are in the definition of terms like "virtual world" and
"region domain." But it was pretty long and rambling and took a long
time to come to the point. I figured I would just come right out and
get to the point.

We want to separate mechanism from policy in OGP.

A bunch of us have been saying it a lot, but I figured it might be a
good idea to clearly explain what I think that means. When I say
"mechanism," I mean things like protocol message formats and
processing expectations; things like, "if you want to login to such
and such a virtual world, you send this message with these fields to
some server out on the network. if the server wants to let you on, it
will send you this message. if it doesn't, it will send you that
message."

Here's an auth protocol exchange example from HTTP:

client: hey! server! gimme the resource at
http://example.org/make/me/a/sandwich.xml
server: no can do, client. that resource is protected. fear my 401!
client: what if i give you my super secret password that i swear i
didn't sniff from another session!?
server: okay. in that case, sure... 200!

Policy, on the other hand, describes the decision making process
protocol participants go through to decide which response to give you.
Returning to the example above, when the server gets an auth request,
it might have the policy of "I will only let people in who give me a
valid avatar or account name and password." Yes! that's policy. It's a
valid idea to let people into a virtual world without a username and
password; web sites do it all the time. For many applications of
virtual worlds, it's a very bad idea, but it's the height of conceit
for me, as a protocol developer, to claim to know the mind of every
virtual world deployer throughout the world.

But, experience tells me that very bad things can happen in some
communities when you add anonymity and an audience. But hey, that's
_your_ call. It could be that your virtual world is only accessible by
two people in the office, so you always have a good idea who the other
"anonymous" participant is. Or maybe you work for an old skool company
where people would never think to be jerks to their fellow employees
in their "behind the firewall" virtual world. The point is... this
decision is up to you, the deployer.

Other examples of policy (again on auth) might include things like:
  * i don't trust MD5, so i'll only accept logins that use SHA1 in some way, or
  * i'll only let you online if i think you've agreed to my "terms of
service" document, or
  * i think i don't want anyone to login between 10PM and 7:30AM
because i'm a BOFH and i need my rest.

There's another term you hear from time to time: "processing
expectations." This is a term I heard first in the SGML / document
processing community. I've seen people attempt to give a formal
definition of this term. My informal definition is... "I know I can't
force you to do this, but everyone sort of expects this is what you're
going to do with the data i give you and it would be really nice if
you would play along, but if you really, really, really need to do
something else with the data, that's cool. KTHXBAI."

An example of a processing expectation might be: "when the server
receives a message with a SHA1 hashed password, it will compare the
hashed password provided with the hashed password stored in the
database." As a client there's absolutely no way I can force the
server to actually do this, but assuming servers do want to maintain
the confidentiality of their users' data, they probably will.

Processing Expectations and Policies are protocol developers' ways of
saying, "krikey! i have no idea what the deployer will want to do
here." or "if the other side wanted to be evil, they could be. look
here! we're trusting them to 'do the right thing.'"

So why do we care?

In the virtual world, one of the things we're really big on is
consistency of presentation. It's considered "a good idea" for you to
see largely the same thing the avatar next to you is seeing.
Otherwise, the utility of the virtual world is diminished.

Some virtual worlds allow user developed content and allow the content
creator to place copy restrictions on that content. (we're not naming
names here, *cough*Second Life*cough*)  Operators of these virtual
worlds have a strong belief it is in their best interest to maintain
those copy restrictions. So... they have a POLICY that says, "when the
client sends me the message to copy a digital asset and put it in
their virtual pocket, i'm going to check if the creator of that asset
says that's okay." The protocol message from the client says "give me
a copy, please" and the server has to decide whether this is a good
idea. If the server thinks it's a good idea, it will do it. If not, it
won't.

Other virtual worlds may be pre-stocked with assets and may not allow
users to create new ones. (i'm thinking this is what sametime 3d does,
but i may be wrong.) Still other virtual worlds may be bastions of
free culture coolness and mark everything with a creative commons
license that allows copying, but leaves it up to the participants to
ensure they're not violating the terms of the license.

I think we have general agreement that people who deploy OGP based
virtual worlds should be free to implement whatever policy they want
to implement. The problem comes when we start talking about allowing
avatars to move between region domains in the same virtual world that
MAY have different policies. Linden Lab, the makers of Second Life,
would want some seriously strong assurances from other region domains
that they promise to honor the permissions metadata attached to a
digital asset. Our hypothetical free culture region domain operators
might want assurances that other region domains will not let assets
with a no commercial use CC license  be used to create things that are
sold.

How will we ever resolve this problem? One way people have tried to
resolve it in the past is by sitting down and writing up legal
agreements. That's because it's a POLICY issue. It's very, very hard
for a server to guarantee by technical means that a client is using
content only in a way the content's rights-holder allows. So we punt,
and just say something like.. "if you sign a contract and let me sue
you if you don't honor my policies, i'll let you interact with my
systems."

As protocol developers all we have to do now is figure a way to tag
content and interfaces with sufficient meta-data that systems in peer
domains have a good chance of making an informed decision when the
client asks to do something that might violate the license. Or, you
might just deny access to service interfaces to people you don't think
you can trust. But again, it's a POLICY decision. As protocol
developers, our responsibility is to specify meta-data sufficient for
making informed decisions and for defining processes for identifying
trusted peers in the networks.

And.. I'm not making an exhaustive list of "policy issues," merely
asserting that there are a reasonably small number of them, and that
we can identify them using a consensus process. By defining these
decisions as "policy issues," it allows us to develop protocol
mechanisms that are appropriate for all supported use cases. Thus we
can all collaborate on producing a specification that works for all of
us, but allows each of us to address our specific needs.

I know Prokofy Neva has made statements disagreeing with this approach
in the past, and that she would prefer a virtual worlds protocol that
mandates all virtual worlds adopt second life's C/M/T permissions
model. I believe her justification is that it's too easy for a
misunderstanding or misconfiguration to lead to content leakage.

My counter argument to this is that by developing the protocol in
public, we get more eyeballs looking at the problem domain and we get
more edge cases considered. Because there's a higher probability that
problematic edge cases will be identified earlier, we'll get a more
robust protocol.

Is there anyone on the list that takes serious issue with anything
i've said here?

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Sun, 23 Aug 2009 00:27:34 +0100

Separation of policy and mechanism is motherhood and apple pie to us here.
The problem lies in achieving it, and avoiding any one party imposing their
own policy by shackling the mechanism and denying it the ability to
implement other policies.

Here's an example of it happening as an artifact of design:

On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[email-masked]>wrote:

I think we have general agreement that people who deploy OGP based virtual
worlds should be free to implement whatever policy they want to implement. *The
problem comes when we start talking about allowing avatars to move between
region domains in the same virtual world that MAY have different policies*.

That's a problem of your own making.  Carlo and I and every open grid
operator understands that all these grids are independent virtual worlds *that
have separate policies*.  Yet you choose to invent a new meaning for
"virtual world" in which *all communicating parties* create a "same virtual
world", and then you wonder why you have a problem of varying policies
within your fictitious "same virtual world".

That's the hub of the matter.  It's not the same virtual world.  It's two
separate virtual worlds with naturally separate policies that are seeking to
interoperate.  You've created the problem yourself by defining them to be
the "same virtual world".

The "same virtual world" terminology in the current OGP documents is
actually *bleeding policy into mechanism*, the exact opposite of the
separation we desire.

It expects uniformity of policies across participating worlds using trust
relationships as tokens of policy conformity.  That's neither feasible on
principle (because the grids have distinct policies by design), nor is it
feasible technically, because it doesn't scale to Internet sizes in a highly
diverse and multi-jurisdictional physical world.

Morgaine.

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

On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[email-masked]>wrote:

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

---

From: Infinity Linden <[email-masked]>
Date: Sun, 23 Aug 2009 00:55:28 -0700

morgaine. redefining terms does not make fundamental issues go away.

the simple fact of the matter is, many of us are interested in
implementing virtual spaces that may be comprised of systems with
multiple owners. some virtual land owners / administrators might not
like some avatars. some users / agent domains may not like some
regions or region domains. whether we define them as all being in the
same "virtual world" or distinct virtual worlds, it doesn't matter,
deployers still need to manage that policy, implementers need to
persist information about policy between protocol interactions and
protocol developers need to identify where policy should be applied.

-meadhbh / infinity

On Sat, Aug 22, 2009 at 4:27 PM, Morgaine<[email-masked]> wrote:
> worlds should be free to implement whatever policy they want to implement.
> The problem comes when we start talking about allowing avatars to move
> between region domains in the same virtual world that MAY have different
> policies.
>
> operator understands that all these grids are independent virtual worlds
> that have separate policies.  Yet you choose to invent a new meaning for
> "virtual world" in which all communicating parties create a "same virtual
> actually bleeding policy into mechanism, the exact opposite of the
> separation we desire.
>

---

From: Infinity Linden <[email-masked]>
Date: Sun, 23 Aug 2009 01:08:07 -0700

-meadhbh / infinity

---

From: Morgaine <[email-masked]>
Date: Fri, 28 Aug 2009 14:46:31 +0100

On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <[email-masked]>wrote:

I couldn't have put it better myself.  And this is why the redefinition of
cross-world interop as taking place in the "same virtual world" will not
make the issues of cross-world interop go away.  We have to face those
issues anyway.  Adding that language achieved nothing and just obscured the
intent.  Clear intent is important.

These problems aren't rocket science, but they do require concentrating on
the actual technical details surrounding asset flow between worlds rather
than handwaving them away with weak, non-technical, non-scalable, and
non-enforceable policy agreements *that are not actual entities in the
protocol*.

The sooner we start addressing the cross-world details at the protocol
level, the closer we will be to an OGP that can actually provide cross-world
interop.  Every mention of trust agreements just waves a magic wand at this
instead of addressing it.

Certificate technology is a given.  It's great for identifying endpoints and
securing sessions, but that's all it does.  It doesn't add magic, and it
doesn't address cross-world interop at all except at the trivial
"no-interop" point.  All the hard work still remains to be done.

A stronger focus on actual networking protocol elements and less
redefinition of non-protocol elements would get us a long way.

Morgaine.

On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <[email-masked]>wrote:

> > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[email-masked]
> >
> > wrote:
> >
> virtual
> > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <[email-masked]
> >
> > wrote:
> >>