Re: [ogpx] Protocol for permitting policy decisions

[Infinity Linden <[e-mail]>]

On Mon, Oct 5, 2009 at 10:54 AM, Morgaine
<[e-mail]> wrote:
> You're opening up a can of worms of biblical proportions here, Mike.
>
> 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
> 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?

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,
> and your value judgements from elsewhere are not importable to those
> 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.

> 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.

 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.

> 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.

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

>
> 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)
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Magnus Zeisig
>> Sent: Monday, October 05, 2009 3:55 AM
>> To: [e-mail]
>> Subject: [ogpx] Protocol for permitting policy decisions
>>
>>
>>
>> -----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.
>>
>>
>>
>> Instead of the revealing (meta-handshake):
>>
>>
>>
>> Agent domain:
>>
>> request access for
>>
>> user: [e-mail]
>>
>> 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: [e-mail]
>>
>>
>>
>> The handshake should instead be:
>>
>>
>>
>> Agent domain:
>>
>> request access for
>>
>> user: [e-mail]
>>
>>
>>
>> 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: [e-mail]
>>
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>