[ogpx] OpenID and OGP : beginning the discussion ...

Infinity Linden <infinity@lindenlab.com> Fri, 26 June 2009 18:24 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBCD3A6A97 for <ogpx@core3.amsl.com>; Fri, 26 Jun 2009 11:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.517
X-Spam-Level:
X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6slXRDnB0HG for <ogpx@core3.amsl.com>; Fri, 26 Jun 2009 11:24:30 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 337893A68F1 for <ogpx@ietf.org>; Fri, 26 Jun 2009 11:24:29 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id c37so839696anc.4 for <ogpx@ietf.org>; Fri, 26 Jun 2009 11:23:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.251.10 with SMTP id y10mr5379274anh.38.1246040627950; Fri, 26 Jun 2009 11:23:47 -0700 (PDT)
Date: Fri, 26 Jun 2009 11:23:47 -0700
Message-ID: <3a880e2c0906261123g4c6c3dbq77029dee0c4b5128@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: ogpx@ietf.org
Content-Type: multipart/mixed; boundary=00163691fe650136d4046d44712c
Subject: [ogpx] OpenID and OGP : beginning the discussion ...
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 18:24:32 -0000

hey peeps.

so a couple years ago there were some preliminary discussions about
integrating OpenID and Second Life(tm). by all accounts, they sorta
went no where. now that a OGP is being defined in terms of LLSD/LLIDL
messages being transported over HTTP (though again... OGP _can_ go
over other transports, we're just starting with HTTP since the
toolchain surrounding HTTP is well developed.) but now that well
defined HTTP messages are a part of OGP, maybe it's time to start
talking about OpenID and virtual worlds again.

so.. there are a couple "issues" with OpenID and desktop applications.
most notably that OpenID concludes it's authentication dance with a
re-direct. as there are limited ways to redirect to a desktop
application (and yes, you could have your application expose a HTTP
service on the local interface to redirect to, but the security
ramifications make it sub-optimal and it's at least as much of a hack
as what we're proposing here.) but as there are limited ways to
redirect to a desktop application, we're proposing that agent domains
that accept OpenID authentication accept a redirect to a service that
responds with a LLIDL/LLSD resource which includes context for
launching the client application. you could apply a unique MIME type
to the message and register the client application as a helper app for
that mime type to ensure the client receives the message from the web
browser.

included in the "launch request message" would be the login URI of the
grid you wish to attach to and info about the agent or account you
want to use to login. since it's an LLIDL/LLSD message, you can add
data fields to the message that might be understandable by one agent
domain, but not another (specifically... if you wanted to tell the
client application to use a different asset server than the default
one for a particular agent domain...)

all the good parts in this draft come from John Hurliman, so thank him
if you like it. if you don't like it, feel free to blame me.

also.. just a note... there's some serious soul searching about
whether the processing expectations section needs to be in a different
draft from the message format definition, or even if all of this needs
to go into the ogp:auth draft and the processing expectations stuff
listed as an option. remember... this is a draft.. it's not set in
stone yet, so if you have ideas about the format or content, please
feel free to bring them up!

-cheers
-meadhbh