Re: [ogpx] Protocol for permitting policy decisions

[Infinity Linden <[e-mail]>]

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)
<[e-mail]> 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: Morgaine [mailto:[e-mail]]
> Sent: Monday, October 05, 2009 12:54 PM
>
> To: Dickson, Mike (ISS Software)
> Cc: [e-mail]
> Subject: Re: [ogpx] Protocol for permitting policy decisions
>
>
>
> 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
>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>