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

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

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


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