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

[Meadhbh Hamrick <[e-mail]>]

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.

--
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/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
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>