Re: [ogpx] Protocol for permitting policy decisions

[Meadhbh Siobhan <[e-mail]>]

again, this is a matter of policy, not a matter of protocol.

let me give you a counter example. some trusted organization, maybe
the new zealand sea scouts, decides it wants a virtual social space to
teach seamanship, knot tying and whatever else scouts are taught these
days.

the sea scouts organization is not really known for it's ability to
maintain a reasonably large networking and system infrastructure, so
instead of building the service themselves, they outsource.

at this point, there are a couple of options open to them. they can
give their entire user database to a third party and hope for the
best. or they can give portions of their user database (name, email
address, adult / minor boolean.) or they could put a VWRAP
authentication service that they maintain in front of their user
database. each are valid options.

one would hope that in the first two options, they worked out with the
third party some pretty hard-core data retention and privacy policies.

so what if they did the third option? what would the protocol have to
do? the sea scout's agent domain would only allow agents to enter a
private virtual world. the sea scouts would negotiate with their
region domain provider to ensure that adult content was not allowed in
the regions accessible by the sea scout agent domain. moreover, the
region domain provider could ensure that ONLY agents with accounts
from the sea scouts would get access to the sea scouts virtual spaces.

so the answer to the question of "what does the protocol have to do?"
is that it only has to convey information about the identity of the
agent domain to the region provider. it also has to have a mechanism
for the agent domain to identify the region.

but the protocol itself does not impose restrictions as to the
identity of either party. that is a policy issue.

in other words, if you don't want to use an agent domain  / region
domain pair that provides information about you to a trusted third
party, don't give that information the the agent domain in the first
place. or double check that the agent domain's privacy policy requires
third parties to which it reveals information to  treat that
information with due care.

that being said, some people's paranoia level is higher than others,
so maybe we could have multiple techniques defined for sharing
sensitive information, none of which are mandatory.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, 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
>
>