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

["Hurliman, John" <[e-mail]>]

> -----Original Message-----
> From: Meadhbh Hamrick [mailto:[e-mail]]
> Sent: Tuesday, July 06, 2010 11:34 AM
> To: Hurliman, John
> Cc: [e-mail]
> 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.
> 
> it doesn't sound like this change will cause heartburn for you, john.
> your thoughts?
> 

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.


> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
> 
> 
> 
> On Tue, Jul 6, 2010 at 10:29 AM, Hurliman, John <[e-mail]>
> wrote:
> > 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
> >
> >
> > On 7/5/10 4:28 PM, Meadhbh Hamrick wrote:
> >> 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/ * [e-mail]
> >> _______________________________________________
> >> vwrap mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/vwrap
> >
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
> >