Subject: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 15:51:53 -0600

> ...
> 
> Great. Now can you please explain to me why this matters for interop:
> http://tools.ietf.org/html/draft-ietf-vwrap-authentication-00
> Not just the title, but the actual content of that draft.
> 

That's the concise example of what doesn't fit that I was looking for, thank you. Honestly, I have no idea how we are furthering interop by standardizing the login process. Maybe it fits in as an authentication step? But--and I'm going to keep using the OpenID analogy here because I think there are a lot of similarities to draw on--OpenID describes its own authentication step as "and then some fill in the blank happens here". They purposely leave it out of scope and only standardize on how you prove ownership of an identity across trust domains, the server-to-server endpoints. That makes more sense to me than saying "and then you send a SHA-256 hash of your password to authenticate, and maybe wait for a maintenance daemon to do some processing, and...". Meadhbh, can you comment on this?

John

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 15:06:45 -0700

John,

You may also want to read the intro draft.
http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

This is in 4.4:

"VWRAP defines formats  for describing objects and avatar shapes, but 
more importantly it
    describes the mechanism by which those digital asset descriptions are
    transferred between client applications, agent domains and region
    domains."
...
"Accessing and manipulating digital assets is  performed via 
capabilities which expose the state of the asset to an authorized client. "

In other words, assets are fetched by the client. So if my world pushes 
them to the client, it's not VWRAP-compliant.

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 16:11:17 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Crista Lopes
> Sent: Friday, September 24, 2010 3:07 PM
> To: [email-masked]
> Subject: Re: [vwrap] Why are we standardizing the login handshake? (was
> RE: one question)
> 
> John,
> 
> "VWRAP defines formats  for describing objects and avatar shapes, but more
> importantly it
> "Accessing and manipulating digital assets is  performed via capabilities which
> expose the state of the asset to an authorized client. "
> 
> In other words, assets are fetched by the client. So if my world pushes them
> to the client, it's not VWRAP-compliant.
> 

You keep saying "if my world does X, it's not VWRAP-compliant". That's not correct. "If my world does not have service endpoint X, it's not VWRAP-compliant" is the correct statement here. Your world can send assets to your client in any way it wishes, but if your asset service does not expose a VWRAP asset fetch capability (regardless of whether your own client uses it or not) then it is not VWRAP-compliant.

John

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 15:16:17 -0700

> You keep saying "if my world does X, it's not VWRAP-compliant". That's not correct. "If my world does not have service endpoint X, it's not VWRAP-compliant" is the correct statement here. Your worl…

So what exactly does this mean? (especially the 2nd sentence, the 1st is 
just for context of the word "client")

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 23:27:20 +0100

The Intro document is beyond repair, and should be quoted only with extreme
caution.

If VWRAP "defines formats for describing objects and avatar shapes" then it
will be obsolete on the day it is released, and utterly unable to stay in
touch with worlds evolving along a thousand fronts.

That's why we have *SERVICES*, so that such issues as objects and avatar
shapes are entirely external to the core protocol, evolving independently,
and negotiated on entry to each new world, or even potentially to each new
region.  That's why regions have the capability to handle multiple assets
services from multiple worlds, so that no central policy applies.  Defining
fixed formats centrally would be an exercise in futility on an Internet
scale.

The Intro document represents OGP legacy, and should not be treated as more
than that.  You have to remember that OGP was about expanding a centrally
managed virtual world.  It bears very little relationship to what we're
trying to achieve.  (And for that, I can only apologize --- OGP should have
been thrown out much earlier.)

Morgaine.

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

On Fri, Sep 24, 2010 at 11:06 PM, Crista Lopes <[email-masked]> wrote:

> "Accessing and manipulating digital assets is  performed via capabilities
> which expose the state of the asset to an authorized client. "
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 16:36:00 -0600

> Sent: Friday, September 24, 2010 3:16 PM
> To: [email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Crista Lopes
> >> In other words, assets are fetched by the client. So if my world
> >> pushes them to the client, it's not VWRAP-compliant.
> >>
> >>
> > You keep saying "if my world does X, it's not VWRAP-compliant". That's not
> correct. "If my world does not have service endpoint X, it's not VWRAP-
> compliant" is the correct statement here. Your world can send assets to your
> client in any way it wishes, but if your asset service does not expose a
> VWRAP asset fetch capability (regardless of whether your own client uses it
> or not) then it is not VWRAP-compliant.
> >
> 
> So what exactly does this mean? (especially the 2nd sentence, the 1st is just
> for context of the word "client")
> 

Let's say I have a blog running Wordpress. The default way to leave comments on the blog is to create an account, confirm the e-mail activation, login, then leave a comment. Wordpress is doing a non-standard login (equivalent to "if my world does X"), which makes it neither compliant with OpenID nor non-compliant with OpenID. It is completely orthogonal.

Now I install an OpenID plugin for Wordpress that allows people to either use the traditional method, or use OpenID authentication when leaving comments. I've added a service endpoint for accepting OpenID authentication, and my blog is now OpenID compliant.

Pushing assets to your client does not make your world non-compliant with VWRAP. Being compliant with VWRAP depends on whether you also have a service endpoint that speaks the VWRAP language, in addition to whatever else your system might be doing.

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 15:41:07 -0700

> Pushing assets to your client does not make your world non-compliant with VWRAP. Being compliant with VWRAP depends on whether you also have a service endpoint that speaks the VWRAP language, in ad…

So why is this prescription in the intro document at all?
  "Accessing and manipulating digital assets is  performed via 
capabilities which
  expose the state of the asset to an authorized client. " (where client 
means the client application, in the context of that section)

---

From: Morgaine <[email-masked]>
Date: Fri, 24 Sep 2010 23:45:16 +0100

+1 John.  Another good explanation.

And it's more than just an analogy, it's directly relevant to VW auth as an
example.

Morg.

On Fri, Sep 24, 2010 at 11:36 PM, Hurliman, John <[email-masked]>wrote:

> Let's say I have a blog running Wordpress. The default way to leave
> comments on the blog is to create an account, confirm the e-mail activation,
> login, then leave a comment. Wordpress is doing a non-standard login
> (equivalent to "if my world does X"), which makes it neither compliant with
> OpenID nor non-compliant with OpenID. It is completely orthogonal.
>
> Now I install an OpenID plugin for Wordpress that allows people to either
> use the traditional method, or use OpenID authentication when leaving
> comments. I've added a service endpoint for accepting OpenID authentication,
> and my blog is now OpenID compliant.
>
> Pushing assets to your client does not make your world non-compliant with
> VWRAP. Being compliant with VWRAP depends on whether you also have a service
> endpoint that speaks the VWRAP language, in addition to whatever else your
> system might be doing.

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 16:47:47 -0600

> Sent: Friday, September 24, 2010 3:41 PM
> To: [email-masked]
> >>>> "VWRAP defines formats  for describing objects and avatar shapes,
> >>>> but more importantly it
> >> correct. "If my world does not have service endpoint X, it's not
> >> VWRAP- compliant" is the correct statement here. Your world can send
> >> assets to your client in any way it wishes, but if your asset service
> >> does not expose a VWRAP asset fetch capability (regardless of whether
> >> your own client uses it or not) then it is not VWRAP-compliant.
> >>
> >>>
> >> So what exactly does this mean? (especially the 2nd sentence, the 1st
> >> is just for context of the word "client")
> >>
> >>
> comments. I've added a service endpoint for accepting OpenID
> authentication, and my blog is now OpenID compliant.
> >
> VWRAP. Being compliant with VWRAP depends on whether you also have a
> service endpoint that speaks the VWRAP language, in addition to whatever
> else your system might be doing.
> >
> 
> which
>   expose the state of the asset to an authorized client. " (where client means
> the client application, in the context of that section)
> 

As Morgaine said, the intro doc is in desperate need of a rewrite. But in this specific case I don't see the conflict. I read that as:

"If my client is trying to fetch an asset from a foreign asset service or save an asset to a foreign asset service, where I don't have the luxury of using my optimized non-standard protocol and will be using the VWRAP interop protocol, then my client will be doing that using one or more HTTP capabilities with carefully crafted protocols."

HyperGrid uses this same model, except assets are only fetched server to server instead of directly from the client. When a foreign user is in a grid, there are a set of capabilities (service URLs in HG terminology) attached to that presence and there is an implicitly defined protocol about how you use the asset service URL to fetch a remote asset.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 15:48:28 -0700

yes. clients request things from servers. user agents and renderers
are frequently clients. simulators can be clients in the sense that
the asset server serves requests from the client.

the way i look at it, "server push" is a type of response to a request
since the server waits for a client to be connected before pushing
assets.

so if you want to interpret server push to be outside the scope of
VWRAP, then i'm okay with not working on it, since no one here who's
going to implement anything VWRAPy is talking about doing it.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Crista Lopes <[email-masked]>
Date: Fri, 24 Sep 2010 15:54:54 -0700

I have a feeling I am the only one taking VWRAP for what it says it is 
in the documents -- intro, authentication, etc.
One of my main assessments was: this is full of irrelevant 
implementation details that should not be part of any protocol for 
interoperability.

On 9/24/2010 3:27 PM, Morgaine wrote:
> The Intro document is beyond repair, and should be quoted only with 
> extreme caution.
>
> If VWRAP "defines formats for describing objects and avatar shapes" 
> then it will be obsolete on the day it is released, and utterly unable 
> to stay in touch with worlds evolving along a thousand fronts.
>
> That's why we have *SERVICES*, so that such issues as objects and 
> avatar shapes are entirely external to the core protocol, evolving 
> independently, and negotiated on entry to each new world, or even 
> potentially to each new region.  That's why regions have the 
> capability to handle multiple assets services from multiple worlds, so 
> that no central policy applies.  Defining fixed formats centrally 
> would be an exercise in futility on an Internet scale.
>
> The Intro document represents OGP legacy, and should not be treated as 
> more than that.  You have to remember that OGP was about expanding a 
> centrally managed virtual world.  It bears very little relationship to 
> what we're trying to achieve.  (And for that, I can only apologize --- 
> OGP should have been thrown out much earlier.)
>
>
> Morgaine.
>
>
>
>
>
> On Fri, Sep 24, 2010 at 11:06 PM, Crista Lopes <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     John,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 15:56:06 -0700

yup. the terms "client" and "server" frequently get confused.

i've already suggested we use the terms "user agent" and "renderer" to
be more precise in our usage concerning what kinds of messages they
generate or consume.

another way we've used the terms relate to who initiates connections.
"servers" are things that sit behind routable internet addresses.
"clients" may live behind NATted firewalls and are the ones that
initiate connections.

On Fri, Sep 24, 2010 at 3:16 PM, Crista Lopes <[email-masked]> wrote:
>>> more
>> VWRAP-compliant" is the correct statement here. Your world can send assets
>> to your client in any way it wishes, but if your asset service does not
>> expose a VWRAP asset fetch capability (regardless of whether your own client
>> uses it or not) then it is not VWRAP-compliant.
>>
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 15:56:06 -0700

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 16:59:27 -0600

I think you're right. Most of the group has been operating under the assumption that intro and foundation docs need to be seriously cleaned up, possibly merged, and brought up to speed with the general consensus that we are sharing on the mailing list right now. But there's an almost even division between people who want the docs rewritten from the ground up and people who want to iterate on the existing docs. I'm in the former camp, but I personally am not going to rewrite the intro and foundation docs so I can't make too many demands.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Crista Lopes
Sent: Friday, September 24, 2010 3:55 PM
To: Morgaine
Cc: [email-masked]
Subject: Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

I have a feeling I am the only one taking VWRAP for what it says it is in the documents -- intro, authentication, etc.
One of my main assessments was: this is full of irrelevant implementation details that should not be part of any protocol for interoperability.

On 9/24/2010 3:27 PM, Morgaine wrote:
The Intro document is beyond repair, and should be quoted only with extreme caution.

If VWRAP "defines formats for describing objects and avatar shapes" then it will be obsolete on the day it is released, and utterly unable to stay in touch with worlds evolving along a thousand fronts.

That's why we have SERVICES, so that such issues as objects and avatar shapes are entirely external to the core protocol, evolving independently, and negotiated on entry to each new world, or even potentially to each new region.  That's why regions have the capability to handle multiple assets services from multiple worlds, so that no central policy applies.  Defining fixed formats centrally would be an exercise in futility on an Internet scale.

The Intro document represents OGP legacy, and should not be treated as more than that.  You have to remember that OGP was about expanding a centrally managed virtual world.  It bears very little relationship to what we're trying to achieve.  (And for that, I can only apologize --- OGP should have been thrown out much earlier.)

Morgaine.

===================================
On Fri, Sep 24, 2010 at 11:06 PM, Crista Lopes <[email-masked]<mailto:[email-masked]>> wrote:
John,

This is in 4.4:

"VWRAP defines formats  for describing objects and avatar shapes, but more importantly it
  describes the mechanism by which those digital asset descriptions are
  transferred between client applications, agent domains and region
  domains."
...
"Accessing and manipulating digital assets is  performed via capabilities which expose the state of the asset to an authorized client. "

In other words, assets are fetched by the client. So if my world pushes them to the client, it's not VWRAP-compliant.

_______________________________________________
vwrap mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vwrap

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 16:01:03 -0700

because we like capabilities for reasons described earlier this week.

i know morgaine likes to say the intro is beyond repair, but if you
actually read it, there are some interesting little nuggets.

like for instance the whole thing about wanting to support loosely
coupled collections of services. capabilities allow us to avoid (among
other things) the confused deputy problem.

as of yet, there's no other proposal for how to address this issue.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 16:03:44 -0700

like what?

what do you not like?

an abstract type system?
capabilities?

what do you want to replace them with?

what are your interoperability objectives?

what are your architectural requirements?

-cheers
-meadhbh

On Fri, Sep 24, 2010 at 3:54 PM, Crista Lopes <[email-masked]> wrote:
> I have a feeling I am the only one taking VWRAP for what it says it is in
> the documents -- intro, authentication, etc.
> One of my main assessments was: this is full of irrelevant implementation
> details that should not be part of any protocol for interoperability.
>
>
> That's why we have SERVICES, so that such issues as objects and avatar

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 17:05:10 -0600

> Of Meadhbh Hamrick
> Sent: Friday, September 24, 2010 4:01 PM
> To: Crista Lopes
> Cc: [email-masked]
> i know morgaine likes to say the intro is beyond repair, but if you actually
> read it, there are some interesting little nuggets.
> 

Don't put Morgaine in a raft by himself on this one. I've made that statement, Jonathan has made that statement, and I believe Crista is making that statement here as well. Everyone else has not weighed in on either direction, so I was being very generous when I said the group is evenly split on the issue. I agree that there are some great bits in the intro doc, but that's why computers have copy paste.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 16:12:52 -0700

if you will remember from last year when we decided to have separate
intro and foundation documents, the intro was intended to put forth
the objectives of this group in details, to describe (in detail) what
makes a virtual experience "second life-like," and to provide an
overview of the the "problem domain." this document was intended to be
"informative" as it did not describe specifications that could be
implemented.

the "foundations" doc _was_ intended to be normative in that it
describe things that can be implemented.

so sure, join them if you absolutely want to. but if you look at the
charter, it DOES seem to indicate we agreed to make two docs. if you
want to smush them together into a single normative doc, great. but
you're going to have to modify the charter. not impossible to do, but
i'm sorta coming up blank on why we would want to go through the
effort.

-cheers
-meadhbh

On Fri, Sep 24, 2010 at 3:59 PM, Hurliman, John <[email-masked]> wrote:
> I think you’re right. Most of the group has been operating under the
> assumption that intro and foundation docs need to be seriously cleaned up,
> possibly merged, and brought up to speed with the general consensus that we
> are sharing on the mailing list right now. But there’s an almost even
> division between people who want the docs rewritten from the ground up and
> people who want to iterate on the existing docs. I’m in the former camp, but
> I personally am not going to rewrite the intro and foundation docs so I
> can’t make too many demands.
>
>
>
>
>

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 24 Sep 2010 17:23:56 -0600

I remember the discussions and I agree with your assessment. Decisions were made, things were written into the intro/foundation drafts and charter, and we've reached a point where several participants feel the current drafts do not reflect the current consensus of the group. If this is the case, what is written in the charter is ultimately irrelevant aside from possibly needing to be changed. You don't gain consensus by saying "this is what our charter says so that's what we're committed to doing" if no one is actually committed to doing it. This is the kind of thing that should really be put to a vote.

> From: Meadhbh Hamrick [mailto:[email-masked]]
> Sent: Friday, September 24, 2010 4:13 PM
> To: Hurliman, John
> Cc: [email-masked]
> if you will remember from last year when we decided to have separate intro
> and foundation documents, the intro was intended to put forth the
> objectives of this group in details, to describe (in detail) what makes a virtual
> experience "second life-like," and to provide an overview of the the
> "problem domain." this document was intended to be "informative" as it did
> not describe specifications that could be implemented.
> 
> the "foundations" doc _was_ intended to be normative in that it describe
> things that can be implemented.
> 
> so sure, join them if you absolutely want to. but if you look at the charter, it
> DOES seem to indicate we agreed to make two docs. if you want to smush
> them together into a single normative doc, great. but you're going to have to
> modify the charter. not impossible to do, but i'm sorta coming up blank on
> why we would want to go through the effort.
> 
> -cheers
> -meadhbh
> --
> > I think you're right. Most of the group has been operating under the
> > assumption that intro and foundation docs need to be seriously cleaned
> > up, possibly merged, and brought up to speed with the general
> > consensus that we are sharing on the mailing list right now. But
> > there's an almost even division between people who want the docs
> > rewritten from the ground up and people who want to iterate on the
> > existing docs. I'm in the former camp, but I personally am not going
> > to rewrite the intro and foundation docs so I can't make too many
> demands.
> >
> >
> >
> >
> >
> Behalf
> RE:
> > one question)
> > shapes are entirely external to the core protocol, evolving

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 16:33:58 -0700

right. you don't get consensus by saying "this is what we put in the
charter," but the charter defines what the group is supposed to be
working on.

if this group wants to work on something different from what's in the
charter, that's great.

but

we're going to have to change the charter.

and i hear no one talking about that.

also, no one has put forth a competing intro doc. if you want this
group to be about something else, that's great, but you SHOULD state
what this group is about rather than grumbling that "the intro is
unsalvagable."

maybe you could list individual bits about the intro that you don't like?

that way, people could discuss the bits of the intro and when you get
an intro, it will be something that you do like.

-cheers
-meadhbh

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 24 Sep 2010 16:33:58 -0700

but

-cheers
-meadhbh

---

From: Morgaine <[email-masked]>
Date: Sat, 25 Sep 2010 00:51:50 +0100

I  recommend spending a few months discussing how the architecture of
interop between VWs is expected to work, defining the core protocol
separately from the services, figuring out how the core protocol interacts
with services in general, reasonably defining the typical services
themselves, describing the main dataflows between services, how the main use
cases are expected to be met using services, which metadata is held and
manipulated in asset services, how unencumbered Creative Commons and other
free-to-distribute assets are handled, and so on.  There's material for many
months there.

Our knowledge of the core protocol and its suite of services is nowhere near
to being documentable currently --- it's still being worked out at a high
level.  When it is, then we'll be able to do a better job of writing an
Intro.  Currently we are much better placed to document individual services,
yet we haven't even done much of an enumeration.

It's early days.

Morgaine.

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

On Sat, Sep 25, 2010 at 12:33 AM, Meadhbh Hamrick <[email-masked]>wrote:

> > I remember the discussions and I agree with your assessment. Decisions
> were made, things were written into the intro/foundation drafts and charter,
> and we've reached a point where several participants feel the current drafts
> do not reflect the current consensus of the group. If this is the case, what
> is written in the charter is ultimately irrelevant aside from possibly
> needing to be changed. You don't gain consensus by saying "this is what our
> charter says so that's what we're committed to doing" if no one is actually
> committed to doing it. This is the kind of thing that should really be put
> to a vote.
> >
> >
> intro
> charter, it
> >> On Fri, Sep 24, 2010 at 3:59 PM, Hurliman, John <
> [email-masked]>
> >> wrote: