Re: [ogpx] Protocol for permitting policy decisions

[David W Levine <[e-mail]>]

So.. to sound like a broken record The policy decisions end up being 
applied to services. To an extent, this sort of implies that the 
enforcement point *has* to be the service, not the "domain" but.. one 
important point right behind this.
There is nothing which prevents a region from letting a front end service 
handle access to it. In particular, one very sane model for handling the 
cap grant to a large cluster of regions is to deploy that on a front end 
box, which handles
all of that separate from the region process, and hands out caps to the 
actual region. 

- David




"Dickson, Mike (ISS Software)" <[e-mail]> 
Sent by: [e-mail]
10/05/2009 01:12 PM

To
Meadhbh Siobhan <[e-mail]>
cc
"[e-mail]" <[e-mail]>rg>, Magnus Zeisig <[e-mail]>
Subject
Re: [ogpx] Protocol for permitting policy decisions






I think I buy it in the case you put forward.  That is if you simplify the 
problem so that AD itself specifies the constraint (the AD in your example 
only carries accounts from the sea scouts).  But what if I'm running 
multiple regions with different policies all served by a single AD? Are 
you suggesting that each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised... If 
I'm running multiple regions, some of which are "Adult" and some are not, 
does treating constraints as outside the protocol require each RD to do 
the age verification (I could make a case the answer is yes since 
"Adultness" might differ depending on who/where I am).  And if so how do 
they do that without getting "sensitive information" that is probably best 
owned by the AD.  Is it reasonable perhaps for a RD to delegate that to 
the AD and provide a mechanism to negotiate the details on connect so I 
can centralize such decisions in a single place?

Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:[e-mail]] 
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; [e-mail]
Subject: Re: [ogpx] Protocol for permitting policy decisions

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