Re: [ogpx] Protocol for permitting policy decisions

[Infinity Linden <[e-mail]>]

yes. we can have per-service policies. that's no big deal. but the software
implementing the service doesn't define policy, the people operating the
service do. the people (i.e. - the authority) is represented in the
specification as the "domain." so when we say "the domain sets policy" we
mean that when we have a bunch of machines, all of which are potentially
running different services, we mean that the owner of the machine running
the service sets the policy, not the developer(s) of the software or the
developer(s) of the protocol. that policy may be to defer policy setting to
a subordinate authority.
for example... on the second life grid, linden is likely to adopt a policy
that regions are squares 256m on a side, and that certain regions may only
be entered by administrators. on regions open to the general public, we may
(and do) subdivide land into parcels and allow our residents to limit who is
allowed to enter their parcels. (so... on mainland regions, we devolve
authority for setting the policy of who enters each region to the region
owners.) we also have a policy that even though you're not allowed to enter
a parcel, you can generally see what's in it.

a different developer may choose a different set of policies. that is, they
may decide not to subdivide regions into parcels, and may refuse to give
non-authorized clients information about items in virtual areas they don't
have access to.

another example might be a "private label agent domain." this would be an
operator or authority (or domain) that sets policies like... "we do not
support MD5 hash for password verification." but their business might be to
operate an agent domain on behalf of other organizations. one of these
clients may decide they have a policy that says "we will only authenticate
requests from IP addresses we believe are in a given locality." so in this
case, the private label agent domain operator devolves policy setting for
geo-location based authentication, but retains the right to refuse to use
the older MD5 based password authentication."

so... throughout the documentation... we use the term "domain" to mean
"a collection
of systems and networks over which control is exercised." the "authority" is
the entity (individual or group) that exercises the control. the
manifestation of the authority's control is (among other things) the ability
to set "policy." authority may be "devolved" to "subordinate authorities."
superior authority may decide which policy clauses to devolve and which to
retain. specific service interfaces deployed by a domain may implement
different policies.

ultimately it should not be the work of this group to determine policies for
domains, or even to provide an exhaustive list of policies. specific clauses
in a policy most likely arise from a specific implementation of the
protocol. it should not be the work of this group to bless any one
implementation and it's determination of how to represent policy. (i have
personally said many times that the effort of this group should not be to
bless Second Life(tm)'s legacy protocol and it's related policies. but this
does not mean that we should bless OpenSimulator.)

can we agree to this wording? can we move on?


On Mon, Oct 5, 2009 at 1:20 PM, David W Levine <[e-mail]> wrote:

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