Re: [ogpx] Protocol for permitting policy decisions

[Morgaine <[e-mail]>]

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) <
[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
>
>