Subject: [vwrap] New Revisions of VWRAP Internet Drafts Published

From: Meadhbh Hamrick <[email-masked]>
Date: Mon, 5 Jul 2010 15:28:32 -0700

from http://blog.meadhbh.org/2010/07/new-vwrap-internet-drafts-published.html :

hey peeps! this is just a quick note to let you know that i just
pushed out several new versions of the following VWRAP Internet
Drafts:

VWRAP : Introduction and Goals
https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/

this is the draft that's intended to be a "gentle introduction" to our
kind of virtual world, the protocol and the documents. i believe it is
"very close" to being fully baked. based on feedback from the mailing
list and face to face meetings, i added a section on deployment
patterns (without using the terms "Second Life" or "OpenSim",) removed
the archaic concepts of agent and region domains, added a document
roadmap and added a few terms in the glossary. also, i fixed up the
references in the back so they *should* be pointing to the most recent
revisions of things.

VWRAP : Abstract Type System for the Transmission of Dynamic Structured Data
https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system/

this one still needs a little bit of work and is essentially the same
as the version published last february. however, we seemed to be
hurtling towards consensus on this one.

VWRAP : Trust Model and User Authentication
https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication/

i added references to the CALM draft, and removed the legacy bit about
agent id's. it's now all account ids, which is what i think we all
said we wanted. MD5 is still in the draft 'cause i wasn't completely
sure we all agreed to remove it. i need to add some more verbiage
about the "trust model," and possibly remove the MD5 references if
that's what the working group wants to do.

VWRAP : Client Application Launch Message
https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch/

this is the draft that describes how we send a message from a web site
to the viewer to launch the viewer. it's intended to support web-based
auth schemes like OpenID and OAuth. i added a little more verbiage
regarding the use of a web capability as the location for an
agent_login resource and tried to make sure the references were
pointing to the right place.

so... i encourage everyone to take a look at these docs and let me
know if you see anything wrong with them.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 10:06:56 -0600

Thanks, Meadhbh! It's great to see that you're still actively engaged
with this work. Now let's get some folks on the list to provide comments. :)

On 7/5/10 4:28 PM, Meadhbh Hamrick wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 6 Jul 2010 11:29:30 -0600

Now that the CALM draft is alive and kicking again let's see how I can break it :-). One issue I ran into while implementing my launcher app was the need to distinguish between capability login URLs and unauthenticated login URLs. Here are our use cases:

a) A user visits sciencesim.com, creates an account and/or logs in, goes to their start page (let's say sciencesim.com/account/) and clicks a Launch button that points to a CALM document with a login capability. The launcher app knows to start the viewer in "pre-authenticated" mode where it skips the username/password entry form and tries to log directly in-world.

b) A user wants to login to sciencesim.com using the username/password entry form built into the viewer, without doing a web authentication first. They have sciencesim.com/launch/ bookmarked which returns a CALM document containing the unauthenticated login url for sciencesim. This instructs the launcher to open the viewer in "username/password prompt mode".

To achieve both of these use cases I added a new &authenticator that contains { "type": "capability" } to distinguish a pre-authenticated URL from the regular variety. I also added a bit of code to look for either "name" or merge "first_name" + "last_name" into a Name field. The full CALM parsing code for the launcher is in SVN at <http://code.google.com/p/openmetaverse/source/browse/trunk/Launcher/LaunchDocument.cs>. You'll notice a couple of non-standard extensions ("welcomeurl", "economyurl", "abouturl", "registerurl", "helpurl", "passwordurl") that are not part of the spec, but used in the launcher app since we're using CALM documents as the hopeful successor to GridInfo documents (http://opensimulator.org/wiki/GridInfo).

John

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 6 Jul 2010 11:33:51 -0700

yay! comments!

a couple comments:

1. didn't we say we wanted to drop the legacy "agent login" and only
go with "account login" ? there was a back and forth where i was all
about "oh noes! SL will break if we don't do agent login?" and then
someone (morgaine?) said "it's okay, SL will cope!" and then josh
said, "yeah, SL will cope without agent login in VWRAP, we can login
with a single account string."

so the most recent auth spec DOESN'T have a first + last agent login
option. it only has an account_name string in the auth request.

it doesn't sound like this change will cause heartburn for you, john.
your thoughts?

2. we had previously said (roughly) "if the &authenticator map is not
present in the agent_login message, the auth service will figure out
what to do on it's own." so the current draft calls out two options
for why the auth service may not see an &authenticator: 1. it's been
pre-authenticated or 2. auth info is present in the transport session
(either by a TLS client cert or HTTP digest auth.)

but... i think i like your way better, john. so, i propose the
following new types for authenticators:

{ "type": "capability" } - as described below
{ "type": "transport" } - the service should check the transport for
either a HTTP digest auth header or a TLS client side cert.

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 6 Jul 2010 12:41:41 -0600

> -----Original Message-----
> From: Meadhbh Hamrick [mailto:[email-masked]]
> Sent: Tuesday, July 06, 2010 11:34 AM
> To: Hurliman, John
> Cc: [email-masked]
> Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published
> 
> yay! comments!
> 
> a couple comments:
> 
> 1. didn't we say we wanted to drop the legacy "agent login" and only go with
> "account login" ? there was a back and forth where i was all about "oh noes!
> SL will break if we don't do agent login?" and then someone (morgaine?) said
> "it's okay, SL will cope!" and then josh said, "yeah, SL will cope without agent
> login in VWRAP, we can login with a single account string."
> 
> so the most recent auth spec DOESN'T have a first + last agent login option. it
> only has an account_name string in the auth request.
> 

This works for me. I wrote that parser when the discussion was still happening and tried to bullet-proof it against the first+last possibility, but it sounds like I need to change name to account_name and it should be safe to drop the first_name+last_name support since there are no other CALM implementations at the moment.  I'll make this change in the next release.

> 2. we had previously said (roughly) "if the &authenticator map is not present
> in the agent_login message, the auth service will figure out what to do on it's
> own." so the current draft calls out two options for why the auth service may
> not see an &authenticator: 1. it's been pre-authenticated or 2. auth info is
> present in the transport session (either by a TLS client cert or HTTP digest
> auth.)
> 
> but... i think i like your way better, john. so, i propose the following new
> types for authenticators:
> 
> { "type": "capability" } - as described below { "type": "transport" } - the
> service should check the transport for either a HTTP digest auth header or a
> TLS client side cert.
> 

This looks good to me.

> > Now that the CALM draft is alive and kicking again let's see how I can break
> it :-). One issue I ran into while implementing my launcher app was the need
> to distinguish between capability login URLs and unauthenticated login URLs.
> Here are our use cases:
> >
> > a) A user visits sciencesim.com, creates an account and/or logs in, goes to
> their start page (let's say sciencesim.com/account/) and clicks a Launch
> button that points to a CALM document with a login capability. The launcher
> app knows to start the viewer in "pre-authenticated" mode where it skips
> the username/password entry form and tries to log directly in-world.
> >
> > b) A user wants to login to sciencesim.com using the username/password
> entry form built into the viewer, without doing a web authentication first.
> They have sciencesim.com/launch/ bookmarked which returns a CALM
> document containing the unauthenticated login url for sciencesim. This
> instructs the launcher to open the viewer in "username/password prompt
> mode".
> >
> > To achieve both of these use cases I added a new &authenticator that
> contains { "type": "capability" } to distinguish a pre-authenticated URL from
> the regular variety. I also added a bit of code to look for either "name" or
> merge "first_name" + "last_name" into a Name field. The full CALM parsing
> code for the launcher is in SVN at
> <http://code.google.com/p/openmetaverse/source/browse/trunk/Launche
> r/LaunchDocument.cs>. You'll notice a couple of non-standard extensions
> ("welcomeurl", "economyurl", "abouturl", "registerurl", "helpurl",
> "passwordurl") that are not part of the spec, but used in the launcher app
> since we're using CALM documents as the hopeful successor to GridInfo
> documents (http://opensimulator.org/wiki/GridInfo).
> >
> > John
> >
> >
> >> this is the draft that's intended to be a "gentle introduction" to
> >> our kind of virtual world, the protocol and the documents. i believe
> >> it is "very close" to being fully baked. based on feedback from the
> >> mailing list and face to face meetings, i added a section on
> >> deployment patterns (without using the terms "Second Life" or
> >> "OpenSim",) removed the archaic concepts of agent and region domains,
> >> added a document roadmap and added a few terms in the glossary. also,
> >> i fixed up the references in the back so they *should* be pointing to
> >> the most recent revisions of things.
> >>
> >> i added references to the CALM draft, and removed the legacy bit
> >> about agent id's. it's now all account ids, which is what i think we
> >> all said we wanted. MD5 is still in the draft 'cause i wasn't
> >> completely sure we all agreed to remove it. i need to add some more
> >> verbiage about the "trust model," and possibly remove the MD5
> >> references if that's what the working group wants to do.
> >>
> >> this is the draft that describes how we send a message from a web
> >> site to the viewer to launch the viewer. it's intended to support
> >> web-based auth schemes like OpenID and OAuth. i added a little more
> >> verbiage regarding the use of a web capability as the location for an