Re: [ogpx] Protocol for permitting policy decisions

[Vaughn Deluca <[e-mail]>]

David wrote

>I would suggest that one good way forward on this is to develop a set of
policy use cases
>to drive our analysis of the protocol and specifications, and then look at
whether we can
>reasonably manage these use cases."

I agree, and the obvious place to start is
http://tools.ietf.org/html/draft-levine-ogp-layering-00 were David provides
a number of deployment patterns:

>5.  Second Life Agent Domain / Region Domain Split
>6.  Standalone OpenSim Region model
>7.  OpenSim OGP + Asset reflector + Agent Service
>8.  OpenSim UGAIM grid model
>9.  Hypergrid
>10. Hypergrid and Cable Beach
>11. Multi-hosted asset deployment
>12. Factored Service Models

I will try to extend pattern 5, and first see how far it can be applied to a
TP between two Regions in different Region domains. I will work towards what
 Morgaine called the tourist model --Morgaine, if i am misrepresenting your
idea please jump in and correct were needed :)

Some features mentioned in pattern 5 are:

(1) The agent domain acts as a unitary focus for all services associated
with the agent.
(2) When accessing other services hosted by a deployer other than the hoster
of the agent domain, the agent domain acts as the trust source, managing the
agent (and user's) access to other regions.
(3) [not considered yet to keep things simple]

I think that these two features can also be used in the tourist model. To
keep things simple at first, lets leave out assets for now, and consentrate
on TP. Also I find it easier to analyse the needs and constrains when using
a real protocol example. The protocol steps for TP have been described in
http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_5. The high level
description in this document is this:

"In all cases, the sequence of resource invocations follows the same form.
First, the Viewer invokes Place Avatar on the agent's Agent Domain. While
processing Place Avatar, Agent Domain asks the destination region if the
avatar can be placed by requesting and invoking the Request Rez Avatar
resource. If the agent is already connected to a region, in the previous
Teleport, the Agent Domain has already stored away the Derez Avatar
capability for that agent.
The Agent Domain passes the Rez Avatar capability to the (stored away) Derez
Avatar capability, asking the current region to transfer the avatar to its
destination. The current region in turn transfers the avatar to the
destination by POST'ing to the Rez Avatar resource. The response to Rez
Avatar is propagated all the way back to the Agent Domain, which passes the
results overlayed with the response from Request Rez Avatar back to the
Viewer. Finally, the Viewer establishes communication with destination
region to begin simulation. "

The Naming convention in the rest of this text is what we used in several
post now: D for domain and S for service, A for agent, R for region.
 Services from different administrative domains get different numerical
suffixes (e.g AD1, AD2). In addition instances of a particular  servicetype
within some domain could be given a second  numerical suffix that identifies
the particular instance  (e.g. RS1.1, RS1.2 and RS1.3 for three region
services belonging to RD1.

The TP-Draft_5 high level description starts with an agent logged in into
AD1, with a rezzed avatar in RS1.1 and a Derez cap for the avatar stored by
AD1.
I have numbered the steps for easy reference and write all calls from left
to right.

(1) Viewer---("place avatar" request for RS2.1)---> AD1
Note that AD1 is is domain, not a service, so i we might need to tighten the
language here a bit also, but for now i will let that go.

(2) AD1 can checks (behind its interface) if its policy will allow this TP,
this is outside the protocol.
If AD1 allows the TP it asks RS2.1 for a "rez avatar cap":

(3) AD1---( "Rez avatar cap" request )---> RS2.1

(4) In this stage RS2.1 can apply its own policy and/or (behind its own
interface) consult RD2 to check global domain policy, as suggested by David
and after that by me, elsewhere in the discussion.  RS2.1 might also want
extra info about agent_ID@AD1. How to do this, and how wise it is has been
the subject of much of the recent discussion.
I liked the multi-message handshake suggestion of Magnus and Infinity, for
example:

(5) RS2.1---(X, age > X? cap)---> AD1
If AD1 does not want to give this information or cannot do so, it does not
use  the cap and reports a failure back to the viewer. Otherwise it uses the
cap:

(6) AD1 ---(POST)----> age > X? cap

If RS2.1 now wants to allow the TP, the  Rez avatar cap is returned (as well
as some other caps that are a bit out of scope here)

(7) RS2.1---( Rez avatar cap)---> AD1

(8) AD1---(Rez avatar cap) ---> Derez avatar cap
The stored Derez avatar cap is a URI pointing to the current region of the
avatar, in this case RS1.1

(9) RS1.1---(POST)---> Rez avatar cap
The Rez avatar cap is un URI pointing to the destination region of the
avatar, in this case RS2.1

(10) RS2.1---( Rez avatar result)---> RS1.1

(11) RS1.1---(Rez avatar result)---> AD1

(12) AD1---(Place avatar result, Rez avatar result)--->  viewer
The viewer can now contact the region.

As far as I can see this fits the tourist model , as well as the deployment
pattern under point 5 in the layering document. (ignoring assets for the
moment).  Am i right? or did i overlook something?


On Thu, Oct 8, 2009 at 3:57 PM, David W Levine <[e-mail]> wrote:

>
> One thing to keep in mind in this whole discussion is the following: "All
> policy decisions are local" This doesn't mean they don't represent a way of
> solving a globally distributed use case, but
> it highlights the fact the one software element, hosted behind and endpoint
> can't impose behavior on another such endpoint. In the case of how a service
> in an Agent Domain interacts with the services in a region domain, the Agent
> Domain is limited to controlling what *it* does. So, in the case of an agent
> domain which has the policy of not permitting its users to be exposed to
> "mature" content. The agent domain, however, doesn't perform the delivery of
> content from the region. It handles authentication, and global presence
> management, and possibly inventory management, but, it doesn't control what
> happens in the region. (In fact, in the current model, it doesn't even see
> the traffic, but seeing it wouldn't help)
>
> The decision as to what happens inside the region is local to the region.
> Just as the agent Dorian in this example doesn't see what the region is
> doing, the region doesn't see what the
> agent domain is doing, nor can it influence it.
>
> From the point of view of the use case "Keep my agents away from "mature"
> content" the Agent Domain's leverage is limited to looking at the
> information the region exports, and deciding whether or not this is a region
> where it is safe for its agents to travel. The region, of course, can say
> whatever it wants. So.. if the Agent Domain wants certainty, it needs for
> the
> region to not only export information it can use to make this decision, but
> to export it in a way that gives the agent domain increased certainty.
>  Traditionally, this takes the form of a
> digital signature tied to real world, out of band assurances.
>
> I would argue this is all for the good. At the Protocol and Endpoint
> description level, most of what needs to happen to support this model is to
> make sure we know where services expose meta-data and how it is formatted.
> The protocol need not focus on what the meta-data represents, but that it is
> there and available for supporting policy decisions.
>
> From the perspective of managing interop, I think that the bulk of our
> focus needs to be having the use cases which enable us to make sure we *can*
> export and understand
> the meta-data needed to allow policy decisions to be made.
>
> There is a related topic, namely how we might do a distributed policy
> language permitting various services to reason about the policies governing
> a given service they wish to interact with. But.. That's not needed to make
> the protocol work. I view this as a good thing, since it is a decidedly non
> trivial problem to solve.
>
> I would suggest that one good way forward on this is to develop a set of
> policy use cases to drive our analysis of the protocol and specifications,
> and then look at whether we can reasonably manage these use cases.  My
> personal belief is that the bulk of our policy management is going to
> consist of checking for meta-data signed using existing PKI standards (x.509
>  is the obvious one) and making decisions based on this meta-data.
>
> - David W. Levine
> ~ Zha Ewry
>
>
>
>
>  *Carlo Wood <[e-mail]>*
> Sent by: [e-mail]
>
> 10/08/2009 07:44 AM
>   To
> Meadhbh Hamrick <[e-mail]>
>  cc
> Infinity Linden <[e-mail]>om>, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <[e-mail]>rg>, Magnus Zeisig <
> [e-mail]>  Subject
> Re: [ogpx] Protocol for permitting policy decisions
>
>
>
>
> On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote:
> > anyway. just a though. i'm going to spend a little time trying to
> > understand a couple different country's regulations for online access
> > to adult materials by minors, just to get a sense for where the
> > differences would lie.
>
> Although admirable, this is just an EXAMPLE. We should look at it,
> and SOLVE it, in an abstract way; so that we will tackle every
> possible policy problem like it without that we have to think of
> an exhausted list now.
>
> Ie, if your investigation would show that every country in the
> world handles online access to adult materials by minors in the
> exact same way, than that doesn't make the abstract problem go
> away, we'd just have to think of another example to tackle the
> exact same problem.
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>