Re: [ogpx] Protocol for permitting policy decisions

["Dickson, Mike (ISS Software)" <[e-mail]>]

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]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Magnus Zeisig
Sent: Monday, October 05, 2009 3:55 AM
To: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>



The handshake should instead be:



Agent domain:

request access for

user: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ogpx