Re: [ogpx] (no subject)

[Kari Lippert <[e-mail]>]

Thanks - and I see from the posts that you referenced that the discussion
initiated in the AD <--> RD exchange. I think by "policy" what is meant is
"access rights", where if I can't answer the questions at the door, I can't
get in, and there may be a series of doors (I can stand in the vestibule, I
can get to the whole place, etc.) which I think is a combination of both
validating my identity (I am who I say I am) and then based on that identity
(and other information TBD) a region implements an access policy.

Regarding the three options, they should all be valid, as should the one we
haven't thought of. The easiest way to do that is with a bit of metadata in
the message header. Ultimately, I think that option a) is a bad idea since
IPs can be spoofed and hijacked. Option b) will require regions to keep
access control determination rules with potentially a third party (think
corporate espionage here).
Having a multi-level handshake seems the best idea. AD knocks (announcing
who I am), RD answers with metadata that enables the AD to determine if they
should/can proceed (this splits access control responsibility to both
parties and is powerful for age based content restriction). After seeing the
region's metadata the AD responds and, if it still wants access, presents
credentials that validate and indicate access "level" entitlement or being
sought. These messages should be of standardized format as specified in the
protocol but should not be restricted to a particular implementation (e.g.
REST).

The first contact (who I am) could be IP-based and the rest could just be
meaningless in a trusted domain situation. I can't envision (other than
through hacking) where this dual message handshake approach would cause
difficulty. It does give the RD a level of protection against inappropriate
access by the AD if the AD presented false credentials.

I have a bit of a problem with
For the Region domain <-> Region service interaction,  option a. will work
perfectly. Since by definition all involved hosts are under the same
administration,
which is probably my misunderstanding but I thought it was not necessary
that the RD and RS are under the same administration. It might be the
reference to the RS that's throwing me here.  I shall go read more....

Kari


On Mon, Oct 12, 2009 at 2:19 AM, Vaughn Deluca <[e-mail]>
wrote:
> Kari,
> I think we should treat AD and RD separately, since they are not
completely
> similar in the way they are currently used. For now I like to stick to the
> region domain. You wrote:
>>I believe we can largely treat the domains as black boxes
>>and not worry their implementation or how they will use the
>>information they receive.
> Yes, absolutely, in any case as far as the region domain is concerned.
That
> domain is only an instruments of policy and administration, and as such
IMHO
> completely out of scope of the protocol, so not only can we can treat it
as
> a black box, we could even completely forget about it in protocol terms,
and
> leave it up to the administrators to use it in whatever way they like,
> behind the endpoints of the protocol.  That said, I *do* think the region
> domain is a useful administrative concept, and an efficient way to
implement
> policy.  Given that fact, a case can be made that we should specify
> something, if only to make clear how we view the concept can be used
> effectively. I have no real desire to do so, but if we go that way, you re
> right:
>>We only need to understand what information a domain would require to
>> accept or >react to a communication. True?
> Yes, i think so. Infinity gave 3 common ways to determine policy at the
> bottom of this post:
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html
>>a. identity implies policy.
>>b. authenticator implies policy.
>>c. region metadata implies policy.
> For the Region domain <-> Region service interaction,  option a. will work
> perfectly. Since by definition all involved hosts are under the same
> administration, the identity of the hosts (is indicated by host name or IP
> address) is all that is needed to tell the domain it can trust the region
> service. The content of the message exchange does not concern us. But if
we
> wished we could provide some examples along the lines Magnus and Infinity
> suggested here:
> http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html
> where  they were discussing solutions for policy exchange between Agent
> Domain and Region Service. I like the third case, were the interaction
> follows the REST style.
> -Vaughn
> On Mon, Oct 12, 2009 at 1:30 AM, Kari Lippert <[e-mail]>
> wrote:
>>
>>  Any service request, invocation, message delivery, or other type of
>> communication attempt with either an AD or an RD will likely require
>> the presentation of some sort of credential. Policy is outside the
>> protocol as it is an implementation detail, but the protocol needs to
>> indicate what would be (minimal) credentials. Clearly we need more
>> than a notional idea of what that information entails. The policies
>> that determine how (or even if) the domain uses that information is
>> clearly up to the domain implementation and beyond the scope of the
>> protocol.
>>
>> While we need to consider the types of things the domains might do so
>> that the protocol supports the transmittal of the appropriate
>> information, we are only specifying a format for communicating
>> information between the domains.  Unless I've missed some critical
>> point somewhere, I believe we can largely treat the domains as black
>> boxes and not worry their implementation or how they will use the
>> information they receive. We only need to understand what information
>> a domain would require to accept or react to a communication. True?
>>
>>
>>
>> Kari
>>
>>
>>
>> On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca <[e-mail]>
>> wrote:
>> > I realise now I have been confused about the meaning of the Region
>> > Domain,
>> > but your post clears up a lot for me.
>> > Some of this has been voiced by others already, but here is my personal
>> > view.
>> > I think the notion of RD is very useful as a tool to specify *common*
>> > policy
>> > for some regions.
>> > Looking at the TP draft, its absolutely clear that the region is the
>> > endpoint, and a rez cap will also point to the region. Yet, as you
>> > already
>> > mentioned *behind* that interface, the region can get some of its
policy
>> > from a region domain "service".  Viewed like this the RD becomes a
>> > lookup
>> > service for information that otherwise has to be duplicated in possibly
>> > a
>> > lot if regions. The RD is not a *front*end containing the regions, but
>> > its a
>> > *back* end service *used* by the regions, and the fact that some
regions
>> > do
>> > use this particular service places them de-facto *in* a that RD.
>> > Since policy it outside the protocol, it is not  needed to specify how
>> > the
>> > regions consults the RD policy "service". All of that interaction is
>> > hidden
>> > behind the interface to the region, and it is up to the deployer of the
>> > region to decide how to deal with this problem. However, if somebody
>> > feels
>> > the need,  I have no objection to formalising the interaction in
>> >  *optional*
>> > protocol steps, that the region can take to help it making policy
>> > decisions.
>> > -Vaughn
>> > On Tue, Oct 6, 2009 at 11:45 PM, David W Levine <[e-mail]> wrote:
>> >>
>> >> From this mornings AWGroupies discussion, I want to try and pin down
>> >> some terminology:
>> >>
>> >> I've been saying "Policy happens at services." I think I need to make
>> >> this more precise, so:
>> >>
>> >> The current model grounds out in Web Services and streams of "events"
>> >> (Notionally delivered in UDP or over an event queue in the current
>> >> discussions) So.. From the bottom up:
>> >>
>> >> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or
>> >> JSON) which defines a web service capability A set of "events" which
>> >> are notionally short, asynchronous and delivered quickly.. (How much,
>> >> content flows in this form is at yet unclear)
>> >>
>> >> Web service endpoints cluster into set of services, which describe the
>> >> bulk of the functionality in the specifications. (Loosely, this tends
>> >> to be the Authentication Services, Region Service, Inventory services,
>> >> Asset Services and IM services) There is nothing in this model which
>> >> dictates how to implement or deploy these services behind the defined
>> >> interfaces
>> >>
>> >> Laid over this lose description we have had the notion of "domains" in
>> >> particular, the Agent and Region domains. The current (somewhat
>> >> backlevel) intro document says:
>> >>
>> >>    The Open Grid Protocol assumes a division between systems offering
>> >>    user / avatar oriented services and systems offering virtual world
>> >>    simulation services.  OGP was designed to support the case where
the
>> >>    administrative authority for agent services is distinct from the
>> >>    authority providing simulation and object persistence services.
 The
>> >>    administrative authority of the former group is termed the "agent
>> >>    domain" while the latter is termed the "region domain."  The
>> >> protocol
>> >>    allows the agent domain and region domain to be distinct; in other
>> >>    words, a user's identity may be managed by one person or
>> >> organization
>> >>    while the virtual world they inhabit may be simulated by hosts
owned
>> >>    by a completely different organization.
>> >>
>> >> Over the past few weeks, there has been a lot of discussion about the
>> >> possible deployment patterns people will support, and the last
>> >> definition of the split I have seen on the lists seems to be
>> >>
>> >> that if it holds the Authentication and Agent ID services its an agent
>> >> domain, and if it holds the Virtual Presence services its a region
>> >> domain. This seems quite reasonable.
>> >>
>> >> There is also the notion, that domains represent administrative
>> >> spans of control, and that services within a domain share policy.
>> >>
>> >> At the same time.. actual policy is mediated by service end
>> >> points. This is to say the moment we can actually apply policy is
>> >> when a remote service requests a capability, or invokes a capability
>> >> or (possibly) delivers an event or message to us on an asynchronous
>> >> connection.
>> >>
>> >> I see two or possibly three bits of confusion here. I'm going to start
>> >> with the basic one, which has come up over the past week.
>> >>
>> >> People keep saying "Region Domain Decides" or "Agent Domain Decides"
>> >> or "The service consults the Agent Domain" I think this muddies stuff
>> >> because it promotes the domain to an active element, when the real
>> >> behavior is "A service endpoint is called, possibly with some special
>> >> tokens,
>> >> possibly, with a negotiation ensuing and the service endpoint acts
>> >> according to its policy."
>> >>
>> >> Now, the service endpoint may well reside inside an administrative
>> >> domain, and may have its policy dictated by its deployer. But without
>> >> an active element, I don't think the domain "participates"
>> >>
>> >> The second thing which concerns me is that we're sort of conflating
>> >> two useful ideas here. One, the split between authenticator and
>> >> holders of agents, and virtual spaces, and the other, a pattern of
>> >> common use in deploying services. I think this becomes increasingly
>> >> strained, as you look at regions interacting with multiple services,
>> >> and with services which fall outside of the agent/region split, and
>> >> yet belong to one or more administrative domains.
>> >>
>> >> So.. I am not suggesting we throw away these concepts, I am suggesting
>> >> that we look carefully at how we are tossing the word around, whether
>> >> we are overloading it, and whether we could better serve our
>> >> developing a shared understanding by being more rigorous, and more
>> >> careful about how we attack some of these concepts
>> >>
>> >> - David Levine
>> >> ~ Zha Ewry
>> >>
>> >> _______________________________________________
>> >> ogpx mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>