Re: [ogpx] Updated deployment and trust draft posted

[Morgaine <[e-mail]>]

Lawson, the short answer must be that it's next to impossible to prescribe
this, and that it's not our job to prescribe it either.  Each person who
sets up access to a particular subservice modifies their personal trust map
at that point.

It really harks back to David's excellent "The Domain Has No Clothes"
cautionary suggestions that domains do not actually exist but are merely
arbitrary circles drawn around groups of services.  The actual fact of the
matter is that *every service* creates a trust point, so your trust map
looks identical to your services map.

The trust situation in VWRAP is no different to that in SMTP or in DNS in a
real-world rollout, in which you can configure a multiplicity of internal
and external services and service forwarders that together make your MTA
service or nameservice work, but in which "trust" is actually a diffuse
concept that is spread around the various access controls to and from each
subservice on which you depend.  And there is no GLOBAL trust model at all:
your full trust does not extend beyond own resources, drops the instant a
3rd party is involved, and plummets toward zero along a chain of
dependencies

The original "two fuzzy clouds" model of OGP absolutely does not capture
this complex situation, and was appropriate mainly in the simplistic model
where a single virtual world that controls policy is being grown with
regions belonging to 3rd parties that have no say on policy.  The trust can
be partitioned into two blocks in that simple situation, but it is not
generic.  That model is no longer appropriate for VWRAP as a whole, but is
only appropriate in particular narrow deployments, whereas other deployments
(such as the example you discuss) do not fit into that model.  *Most* will
not fit, because most will involve sharing resources and hence be complex.

I think we really have a problem with shedding the shackles of OGP legacy
here.  The two-Domain model was cute and served its purpose as a starting
point, but in a protocol that embraces interop between multiple independent
worlds it is not generally useful, and worse, it is preventing us from
discussing per-service trust control.

I think a line I gave earlier deserves highlighting as a maxim:


*Your trust map looks identical to your services map.
*


There really isn't any escaping this reality, because that's how we
implement multi-part systems with 3rd party dependencies in practice.


Morgaine.




===================================

On Thu, Feb 25, 2010 at 7:14 AM, Lawson English <[e-mail]> wrote:

> I see an issue where there is a presumption of external "authority" with
> respect to services. A client plugin might provide a vwrap service only to a
> client via a localhost/loopback mechanism, or it may be a proxy to a central
> service or it may be a proxy to a p2p network of services. Where does
> administrative authority lie in this scenario? Does it pertain? Who decides?
> etc...
>
> lawson
>
>
>
> Infinity Linden (Meadhbh Hamrick) wrote:
>
>> good draft... so... since there's no trust model and deployment pattern
>> deliverable in the charter, do we want to split this one up and put the
>> deployment stuff in the intro and the trust stuff in the auth draft?
>>
>> here are some comments:
>>
>> * eek! you mentioned Linden Lab(tm) and Second Life(tm) in the draft.
>> given last week's conversation about "second life-like" vs. "vwrap-like" as
>> a descriptor, shouldn't we avoid such things for fear of people thinking
>> that if they're SL-compatible, they're automagically VWRAP-compatible?
>>
>> * i love the picture of User 1 <-> Client 1 <-> service <-> Client 2 <->
>> User 2. it's kind of an oversight that i didn't put something like that in
>> the intro doc. (though i would show it with multiple services.. something
>> like
>> https://wiki.secondlife.com/w/images/d/da/Vwrap_user_to_service_mapping.png)
>>
>> in a related issue. we use the term "client application" for an app that
>> accesses services. the most visible client application is the one that
>> renders the virtual world for the user. i think this kind of application is
>> traditionally called a "user agent" in other IETF protocols. so...
>>
>> question : does it make sense to introduce the concept of a "user agent"
>> as the client application that is intended to have direct interaction with
>> the user?  i think it would be good to explain that "clients" or "client
>> applications" do not always have to be "user agents." if so, lemme modify
>> the intro doc to reflect it.
>>
>> * i would argue that the definition of a "domain" IS defined. as we
>> agree'd on the list, we use the term "domain" in it's classic meaning: "a
>> domain is a collection of network hosts under the control of a single
>> administrative authority."
>>
>> there was an unfortunate confusion of the term "domain" with
>> "administrative authority" as well as the convolution of the terms "domain"
>> and "network host." the existing documents describe a domain in this manner,
>> highlighting an "agent domain" as a domain that includes a user
>> authentication service and a "region domain" as a domain that includes a
>> region object presence service. i'm still not sure why we have to change
>> this.
>>
>> david, i understand that your preference is to have domain mean "the
>> collection of machines which combine to deliver a service." this is going to
>> get confusing when a "domain" crosses "trust domains." in other words, if
>> you have machines owned by one person delivering half of a service and
>> machines owned by another person delivering the other half of the service,
>> and you want to call both sets of machines taken together "a domain," then
>> it will get confusing to also call the set of machines owned by the first
>> person (even the ones that aren't delivering the service in question) "a
>> domain."
>>
>> so... i think we have a couple of different concepts here, and we have to
>> name them different things. maybe we could compromise... we could say that a
>> domain is "a collection of hosts that share some common feature" and that a
>> "trust domain" is a collection of hosts with the same trust characteristics
>> (defined as being owned by the same entity or for whom there's a
>> demonstrable privilege implying trust) and a "service domain" is a
>> collection of hosts that together, deliver a service with the special note
>> that a service domain may cross trust domains.
>>
>> ugh. that was a mouthful.
>>
>> * yup. the glossary in the intro should be beefed up. i'll add some to it.
>>
>> <comment mode="pedantic">
>> * why are we mentioning hypergrid? they've publicly said they don't want
>> to participate. can we remove mentions of hypergrid from these specs? i have
>> no problem with individuals who participated in hypergrid from participating
>> in vwrap (like i could do anything to prevent it.) but... vwrap IS NOT
>> hypergrid. vwrap is also not Second Life. vwrap is also not OpenSim, OSGrid,
>> reactionGrid, cable beach or realXtend.
>>
>> i think we need to be very clear about the relationship between this
>> effort and these projects. as i see it, vwrap is an effort sponsored by the
>> IETF which is intended to be useful by all of the projects listed above, but
>> not to "be" them.
>> in other words, i have a big problem with using the ostensive definition
>> when describing vwrap service definitions. i don't want to ever have a spec
>> that says (and i paraphrase here) "readers are referred to hypergrid
>> specification 3.71 for how vwrap handles authentication to an asset service
>> and the legacy second life protocol as defined in the beginning of file
>> llagent.cpp from the snowglobe source code."
>>
>> on the other hand... getting people from all of the projects mentioned
>> above together to define protocol and usage profiles is a bag full of win.
>> but we should be able to define the characteristics of these systems
>> independent of their names. or rather, we should talk about characteristics
>> of protocol and use and then maybe say ("like hypergrid" or "like opensim".)
>>
>> sorry for going all pedantic on people. just think strongly it would be a
>> train wreck to do this thing that is probably not what david is saying we
>> should do, but scares me nonetheless.
>> </comment>
>>
>> * i think you've got some good ideas WRT trust. however... can we avoid
>> talking about content management IN the protocol? it's a can of worms and
>> IMHO is out of scope and needs A LOT more research. that being said... yes,
>> it's important and we MUST talk about it, but maybe we could add it to a
>> separate document?
>>
>> in other words, i propose adding bits about trust between hosts in the
>> authentication document, but not about content management.
>>
>> -cheers
>> -meadhbh
>>
>> --
>>  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
>>        http://wiki.secondlife.com/wiki/User:Infinity_Linden
>>
>>
>> On Wed, Feb 24, 2010 at 09:30, David W Levine <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>
>>    Dear all:
>>
>>    I have updated the deployment patterns and trust draft with
>>    significant new material and (hopefully) typos removed.
>>
>>    I look forward to comments and feedback. On the list please. I will
>>    happily take typo nits and formatting suggestions off list, but
>>    substantive feedback should be directed to the list for everyone
>>    to see.
>>
>>    Text at:
>>
>>    _http://www.ietf.org/id/draft-levine-vwrap-deploy-01.txt_
>>
>>    - David W. Levine
>>    ~ Zha Ewry (in Second Life)
>>
>>
>>    _______________________________________________
>>    ogpx mailing list
>>    [e-mail] <mailto:[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
>