Re: [vwrap] vwrap Digest, Vol 11, Issue 24

[Morgaine <[e-mail]>]

Oh, that sounds fine then, Sean.

(It was only your final part concerning grid-to-grid authentication that
gave it all the bad properties and dangers that I highlighted.)

Your suggestion about multiple authentication services seems to be very much
in line with our avoidance of singletons.  No matter how much one might like
a universal single sign on, worlds are going to employ a diversity of
authentication systems and we will need to adapt to that, otherwise users
will be unnecessarily restricted in the worlds to which they can travel.

Morgaine.





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


On Thu, Mar 31, 2011 at 5:44 AM, Sean Hennessee <[e-mail]> wrote:

> On 3/30/11 5:17 PM, Morgaine wrote:
>
>> That's a good requirement, Sean.
>>
>> However, you're suggesting a rather inflexible way of achieving it,
>> because it would rely on one world giving you access to another world.  This
>> doesn't scale at all when you consider thousands, let alone millions, of
>> destination worlds.
>>
> I think you misunderstand my example.
>
> The 'Grid Y' authentication service that was used in the example is the one
> that the end user _chose_ to use, not forced by a restriction of it's
> current grid or poor protocol definition. They would have the option to
> choose any authentication service they want, like OpenID, Facebook, Google,
> their home grid's authentication service, or their own home grown
> authentication service they are running for themselves. They could even have
> the option to connect to a grid that does not require authentication. Some
> grids will allow only a few authentication methods/services; some grids
> won't allow any except their own, and some grids won't care.
>
> An additional thought would be having the ability to have a list of
> authentication services that you, the end user, are willing to use, (via
> some preferences in the client viewer application), leaving the negotiation
> process to determine which one to use, (or none at all), for that particular
> destination grid.
>
> Other options that could be negotiated during the authentication phase
> could be asset services used, IM services used, voice services used, etc.
> These would not necessarily be options set by the end users current grid,
> but by the end user herself, (through the viewer client program likely). As
> above, some grids may accept any asset service, or only a limited list of
> trusted asset services, or none at all except it's own. This should not be
> limited to only one of each service, either. I commonly login to Yahoo and
> AIM at the same time to connect with friends that are only connect to one
> service or the other.
>
> There really has to be some kind of negotiations, otherwise you could be
> doing the equivalent of telling Google that you planned to login to their
> webmail service using AOL's Instant Messenger authentication services,
> whether they allow it or not.
>
> Peace,
> Sean
>
>> Also, it would result in balkanization of the metaverse, as restrictive
>> world operators seek to prevent you from travelling to worlds they don't
>> like.  We'd end up with prison enclaves in which the only way for inmates to
>> "escape" to visit friends in non-permitted worlds would be to log out from
>> this prison and log in to a different one, which defeats most of the
>> benefits of VW interop.  It's a poor approach.
>>
>> Fortunately there is a much better way to achieve this, and David hinted
>> at it when he wrote about the near impossibility of one world forcing local
>> policy onto services run by somebody else.  If your assets are not held by a
>> world operator but in an independent external asset service (which could
>> even be on your local system), then you don't need to ask the current world
>> for "permission" to teleport to some other world, since you (or your
>> external asset service) can supply all of the resources needed by the
>> destination world directly.  No more prison planet.
>>
>> The Web doesn't usually provide a good analogy with virtual worlds because
>> its architecture is substantially different in several areas.  However, in
>> respect of teleports the analogy is a direct one.  One world should not
>> limit your ability to teleport to another world any more than one website
>> should have a say on which website you visit next.
>>
>> In summary, the inter-world teleport requirement that you describe is a
>> good one, but it should not be implemented as a cooperative agreement
>> between worlds because that has very negative repercussions for residents,
>> turning them into hapless inmates and splitting communities apart.
>>
>> Instead, VWRAP provides the excellent concept of independent external
>> shared asset services which can serve content to multiple worlds.  Using
>> them we can design a teleport protocol that empowers users and helps the
>> open metaverse bloom, instead of enslaving them and balkanizing worlds into
>> non-communicating factions.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> ======================
>>
>> On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>    So, for example, one protocol we would like to define, in the name
>>    of VW interoperability, is how a client, (a viewer and it's user
>>    in this case), communicates, to a specific grid X authentication
>>    server, that it wants to connect to that grid using grid Y
>>    authentication server, which could be another grid or facebook,
>>    etc. The communication that happens there needs to have some way
>>    to determine if that grid Y authentication service is allowed or
>>    known, and if it was successful in authenticating you, among other
>>    things. So, this is, in a way, service level interop, but like you
>>    said, a bit orthogonal. Also, in addition to the communication
>>    between the above service and client, there would have to be
>>    communication between grid X authentication service and grid Y
>>    authentication service. More protocol this group would likely
>>    specify, I assume.
>>
>>    Peace,
>>    Sean
>>
>>
>>    On 03/30/2011 03:40 PM, Morgaine wrote:
>>
>>        Very well put, Vaughn.
>>
>>        Regarding "service level interoperability", it's not really a
>>        subset of
>>        VW interoperability at all, but lies orthogonal to it because
>>        it is a
>>        property of all multipart systems that implement services.
>>         I'll try to
>>        explain.
>>
>>        Client-server systems for example have at least two distinct
>>        parts with
>>        distinct roles, server(s) and client(s).  Service-level
>>        interoperability
>>        typically consists of designing and specifying the protocols or
>>        interfaces between them in such a way that any part of the
>>        system is
>>        interchangeable with another equivalent part that performs the
>>        same
>>        role, say from a different manufacturer, and the system as a
>>        whole still
>>        continues to work normally.
>>
>>        This rarely needs to be honored with a fancy title such as
>>        "service
>>        level interoperability" in these days of IETF standards and highly
>>        cross-platform web applications.  Historically however,
>>        applications did
>>        not behave quite so nicely, and vendors often sought to lock
>>        customers
>>        in with hidden proprietary interfaces, so there was a need for
>>        adding
>>        "service level interoperability" to the tendering
>>        documentation in days
>>        gone by, to avoid surprises later on.
>>
>>        Today, the need for that has almost disappeared, and if your
>>        online
>>        service has a documented protocol interface then "service level
>>        interoperability" is virtually assured without doing anything
>>        at all,
>>        assuming normal commonsense has prevailed during development
>>        (and there
>>        is no deliberate obfuscation of course).  There is only one
>>        other area
>>        of this topic where a little more needs to be said.
>>
>>        Protocol messages can normally be validated syntactically to a
>>        strong
>>        degree, and whether a message is correct or not is normally known
>>        immediately upon syntactic validation.  Unfortunately, that is not
>>        always the end of the story, because protocols can transport
>>        complex
>>        data items which are valid syntactically yet invalid semantically.
>>
>>        This is the last vestige of where that term is commonly
>>        encountered, as
>>        *Service Level Semantic Interoperability*.  Is it relevant to
>>        us?  Yes,
>>        a little.  For example, it would do us no good to transport
>>        Collada
>>        meshes from an asset service to a client that tries to render
>>        them as
>>        some other graphics format --- that would create a semantic
>>        mishap,
>>        because one party thinks that the items means one thing and
>>        another
>>        party applies a different semantic.  So yes, there is a little
>>        more for
>>        us to consider here, but it's not a lot.  In most part we have
>>        already
>>        stated the solution every time that we have mentioned MIME
>>        types for
>>        describing content.  This is mostly a solved problem.
>>
>>        There may be one or two other areas where we have to specify the
>>        required semantic alongside the simple matter of protocol
>>        syntax, but
>>        that's a standard part of defining protocols.  There is
>>        nothing really
>>        new here.
>>
>>        Lastly, service level interoperability focuses entirely on single
>>        services and their clients, so it's unrelated to interoperability
>>        between multiple services, such as a set of virtual world
>>        services.
>>        This means that, apart from defining type semantics, it
>>        doesn't get us
>>        even a step closer towards interop between virtual worlds.
>>
>>
>>        Morgaine.
>>
>>
>>
>>
>>
>>
>>        ==========================
>>
>>        On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca
>>        <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail]
>>        <mailto:[e-mail]>>> wrote:
>>
>>           Katherine wrote:
>>        >It seems to me that accomodating "full" interop only would
>>        reduce the
>>        >number of possible implementers and use cases for our work
>>
>>           I am sure that nobody  suggested to we restrict ourselves
>>        to "full"
>>           interop only.
>>           "Service level interop" is clearly subset of VW
>>        interoperability. You
>>           can't have VW interoperability without service level
>>        interoperability!
>>           However, If i understand Morgaine right, she is worried
>>        that the VWRAP
>>           specs will be *restricted* to service level interop only.
>>
>>           It has been argued (sorry, I forgot by whom) that proper
>>           specifications of service level interop will give us
>>        virtual world
>>           interop for free. I think we need a bit more, but i really
>>        have a hard
>>           time envisioning how service level interop can be specified
>>        in such a
>>           way that it *prevents* VW interop, at least not if we pay
>>        attention to
>>           this aspect, and clearly we do. So in conclusion i do not
>>        see much of
>>           a problem.
>>
>>           Izzy wrote in another tread "This whole argument between
>>        service level
>>           interop and 'full' interop eludes me." At first it eluded
>>        me to, but
>>           now i think that what is actually expressed in these
>>        discussions is
>>           the question of the scope of our effort as well as design
>>        approach.
>>           Some prefer to work bottom up, following their primary
>>        interests in
>>           getting the low level protocols working, especially since
>>        that will
>>           already be good enough for (all?) of their use cases . Some
>>        prefer a
>>           more top-down approach, first sketching the high level
>>        picture of the
>>           users perception of VW interop,  and from there working
>>        downwards,
>>           obviously also because that approach optimises the
>>        realisation of
>>           *their* use cases.
>>
>>           I think we need both, and above all, i do feel that the two
>>        approaches
>>           are not al all incompatible and both are without any doubt
>>        square
>>           within the current charter.
>>           Formally splitting our effort in two working parties along
>>        the current
>>           visible fissures and getting each to work on their own
>>        interest is a
>>           recipe for disaster. It will only strengthen the animosity
>>        that is
>>           already slowing us down tremendously, and will sustain the
>>        infighting.
>>           Rather than spitting efforts off, we need to address the
>>        causes for
>>           the current disagreement and found common ground.  In my
>>        view that is
>>           not all all hard.
>>
>>           I have been reviewing the discussion we had in September
>>        and i am
>>           actually amazed at the level of consensus that is expressed
>>        in those
>>           email exchanges. Unfortuanately we have been very bad at
>>        consolidating
>>           that consensus. As a result we recycle the same problems
>>        time and time
>>           again. The archives make very depressing reading from that
>>        point of
>>           view. We need to do more documentation for sure.
>>
>>           I am currently going over the September discussion and
>>        looking up the
>>           places were we all agreed on the way forward.  Much of that
>>        is still
>>           undocumented, and my aim is to get those points written
>>        down in the
>>           wiki.
>>
>>           As i final point i want to make clear how I understand the term
>>           "Service Level Interop". I used the term, and since the
>>        glosary entry
>>           is still emtpy, i feel obliged to add at least my personal
>>        reading. If
>>           somebody disagrees, please add an improved version.
>>
>>           Service level interoperability:
>>                   A subset of "Virtual World Interoperability" as
>>        defined by
>>           the VWRAP
>>           protocol. Service level interoperabity loosely describes
>>        specific
>>           interactions between VWRAP endpoints. These inteactions
>>        form the glue
>>           that hold a particular virtual world together, but might
>>        just as well
>>           be used for communication between different VWRAP
>>        compatible virtual
>>           worlds (i.e. crossing trust domains).
>>
>>           I intend to put this up in the glossary, but first will see
>>        how it
>>           flies here  :)
>>
>>           On 3/29/11, Katherine Mancuso <[e-mail]
>>        <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>        > Hi everyone,
>>        >
>>        > I want to speak up for agreeing with Meadhbh & Mike about
>>        keeping a
>>        > role for service level interop in this group.  We've made good
>>        > progress towards this goal and can continue to work on it.
>>        >
>>        > Here is an alternative proposal to any which has been
>>        brought up so
>>        > far.  I'm aware this may not be fully correct in its technical
>>        > details, as I am not a software architect:
>>        >
>>        > Could the partisans of "full" VW interop consider working
>>        together on
>>        > a draft specification that is something like the intro or
>>        David's
>>        > piece in scope that lays out which specific capacities would
>>        need to
>>        > be supported at a minimum to allow for "full" interop, perhaps
>>           getting
>>        > input from implementers such as the Hypergrid folks and the
>>        folks who
>>        > coordinated the teleport test at Linden?  Citing existing
>>        service
>>        > specifications (either ones developed within this WG, or outside
>>        > specifications like XML, Collada, etc) is preferred, and for
>>        > capabilities for which there are not existing service
>>        specifications
>>        > or the existing specifications don't work well enough, address
>>           that to
>>        > lay out a clear roadmap of what must be developed.
>>        >
>>        > My vision here is that folks who are doing service-level
>>        work could
>>        > continue developing and implementing their individual
>>        services, and
>>        > the folks who wish to do "full" interop could define a menu of
>>        > services which must be implemented for "full" interop.
>>         Implementers
>>        > could then choose their path based on their use cases:
>>        implement the
>>        > "full" interop specification including all the
>>        specifications called
>>        > for, or implement individual services.  I believe that both
>>        of these
>>        > concepts can exist under our existing charter or with limited
>>        > amendment to the charter and intro, which is much easier for
>>        everyone
>>        > to agree to than entirely rewriting both, and does not require
>>        > trashing years of work.
>>        >
>>        > It seems to me that accomodating "full" interop only would
>>        reduce the
>>        > number of possible implementers and use cases for our work
>>        > dramatically, not to mention cut out a productive body of
>>        folks in
>>        > this group who have been contributing an awful lot of
>>        documents and
>>        > implementing.
>>        >
>>        > For example, to illustrate my point:
>>        >
>>        > From my work as a SL developer focusing in education, I know
>>           there's a
>>        > substantial use case in K-12 education in the US for walled
>>        gardens,
>>        > because schools have big legal liability problems with
>>        letting minors
>>        > wander unwalled virtual worlds (most school libraries in the
>>        US have
>>        > internet filters for the same reasons) and have fairly intense
>>        > supervision requirements which require substantial moderation &
>>        > surveillance tools.  However, a shared asset server that
>>        contains a
>>        > core of "safe" content might be of interest to these folks,
>>        since
>>        > educators don't necessarily need to reinvent the wheel for their
>>        > classrooms every year.  This is a really good case for
>>        service level
>>        > interop ... implement the asset server specification only,
>>        not the
>>        > "full" one that allows you to teleport to other worlds.
>>        >
>>        > On the other hand, universities have far greater interest in
>>        letting
>>        > students and professors teleport among university spaces (which
>>        > happens metaphorically in the real world all the time), and
>>        fewer
>>        > liability issues.  Sharing an asset server might be of
>>        interest to
>>        > them, but so too might "full" interop.  They'd want to
>>        implement the
>>        > "full" interop specification.
>>        >
>>        > (Paging Fleep Tuque, are you here to make this case better
>>        for me?)
>>        >
>>        > TL;DR - Proposal is to amend the charter & intro so that
>>        they allow
>>        > the "full" interop people to work in one community on their
>>        ideas and
>>        > the service level interop people to work in parallel on
>>        their ideas,
>>        > rather than assuming that one model has to exclusively
>>        dominate the
>>        > group.
>>        >
>>        > I will be unavailable to post anything else much lengthy through
>>           3 April,
>>        > FYI.
>>        >
>>        > Katherine
>>        >
>>        > --
>>        >
>>
>>  ---------------------------------------------------------------------------------------------
>>        > Katherine Mancuso
>>        >
>>        > ISIS Inc, Community Manager (http://www.isis-inc.org)
>>        > Sex::Tech Conference, Social Media Chair
>>        (http://www.sextech.org)
>>        > The Vesuvius Group: metaverse community builders
>>        > (http://www.thevesuviusgroup.com)
>>        > GimpGirl Community Liaison (http://www.gimpgirl.com)
>>        >
>>        > http://twitter.com/musingvirtual
>>        > http://facebook.com/kmancuso
>>        > http://www.linkedin.com/in/kathymancuso
>>        > Second Life: Muse Carmona
>>        >
>>
>>  ----------------------------------------------------------------------------------------------
>>        > _______________________________________________
>>        > vwrap mailing list
>>        > [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>
>>
>>        > https://www.ietf.org/mailman/listinfo/vwrap
>>        >
>>           _______________________________________________
>>           vwrap mailing list
>>        [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>
>>        <mailto:[e-mail]>>
>>
>>        https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>>
>>        _______________________________________________
>>        vwrap mailing list
>>        [e-mail] <mailto:[e-mail]>
>>        https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>    --
>>    Sean Hennessee
>>    Central Computing Support
>>    Office of Information Technology
>>    UC Irvine
>>
>>
>>    ... . .- -. /  .... . -. -. . ... ... . .
>>
>>    _______________________________________________
>>    vwrap mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>