[ogpx] Using the LoginURI as a capability with the Client Application Launch Message
Arrogant Cyberstar <arrogant.cyberstar@gmail.com> Mon, 01 February 2010 23:26 UTC
Return-Path: <arrogant.cyberstar@gmail.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 2BFF83A686C for <ogpx@core3.amsl.com>; Mon, 1 Feb 2010 15:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.358
X-Spam-Level:
X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
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 A0Fir8UOSpNs for <ogpx@core3.amsl.com>; Mon, 1 Feb 2010 15:26:18 -0800 (PST)
Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 1C4273A67B0 for <ogpx@ietf.org>; Mon, 1 Feb 2010 15:26:18 -0800 (PST)
Received: by pxi16 with SMTP id 16so5321258pxi.29 for <ogpx@ietf.org>; Mon, 01 Feb 2010 15:26:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LFuohZ5o8RmuJkNleldNQKdvXNtTmK/aTV8p9I7RVrI=; b=IAqSC5iJVxS/VW05sf4hS/j8+UC8Q1QgGptchqU+v+ocSH5jlkfdH3nVt9DBj5bKYl kkKoHGSfK0R+u2YryRy58AvFOMlsYDe5in2h5h+ffPKL5oPZs8dxZ7XyrAA8PFj7myDO 2xU1x9fy/YmtlQKK9TzDyswuneLpftKiI8uN4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PzBkry3VndhSf+xxIhPm2/Hlago4Mvjsp3orLQ02u7qYYAhy2l7ZVPLAy/9HFvUlFy dG49bAHyJwpR1m1hJZrA9x/jVBR09oTnawy3dWpI8Cfyt5h/p0yzNOUshRaO6psaSFVN OLc1PNV4/9aIDFK8K65zqbTPAmYesFepAygoo=
MIME-Version: 1.0
Received: by 10.114.90.16 with SMTP id n16mr3524501wab.48.1265066810417; Mon, 01 Feb 2010 15:26:50 -0800 (PST)
Date: Mon, 01 Feb 2010 15:26:50 -0800
Message-ID: <5cca23bc1002011526n5dbdd813s8cfe408bd6ea130b@mail.gmail.com>
From: Arrogant Cyberstar <arrogant.cyberstar@gmail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary="0050450293b0da242f047e9251b4"
Subject: [ogpx] Using the LoginURI as a capability with the Client Application Launch Message
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: Mon, 01 Feb 2010 23:26:19 -0000
There was a conversation in the #opensim-dev IRC channel recently where some minor changes to the Client Application Launch Message and the Service Establishment drafts were discussed. The discussion is being repeated here to include the wider audience of persons interested in VWRAP. The two documents in question are at: * http://tools.ietf.org/html/draft-hamrick-ogp-auth-01 (auth / service establishment) and * http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 (client app launch message) The first draft describes the LLIDL resources for VWRAP authentication. It presupposes those resources are accessible at a fixed, well known URI (termed the LoginURI.) The second draft describes the format and processing expectations for a VWRAP Client Application Launch Message. The launch message is generated by a web server as the result of successful OpenID authentication or OAuth authorization. The draft defines a MIME type to contain this message, and it is assumed the user's browser will register a VWRAP viewer application to handle that type. When the viewer receives the message, it would pass its contents along to the VWRAP client application which would use information inside it to begin a UA session with an agent domain. Specifically, the message would contain a username / password pair (where the password may be a short term temporary shared secret) as well as the URI of where to initially place the user's avatar. The contents of the message were defined as LLIDL maps, and could therefore include additional information (such as protocol endpoints for inventory services.) The launch message draft requires the use of SHA256 to hash a randomly generated secret shared between the web authentication / authorization service and the agent domain. It was proposed that rather than sending a shared secret to the client to be used with a resource on a fixed URL, the system should allow the LoginURI to be a capability. That is, it should allow the use of a launch message with a null authenticator, but with a cryptographically unguessable URL. The specific changes to the launch message draft would include: 1. Referencing the authentication schemes in the auth / service establishment draft rather than defining new ones in this draft. 2. Rewording the specification to indicate the processing expectations: a. if an authenticator map entry is present in the launch_request, the loginuri should be considered well known and the client SHOULD use the values in the authenticator map in conjunction with service establishment. b. if the authenticator map entry is NOT present in the launch_request, the loginuri should be considered a capability and clients should take due care in handling it's concents, and MUST NOT include an authenticator map in the authentication request. Changes to the authentication / service establishment draft would include: 1. explicit mention of the "null" authentication scheme. that is... if the authenticator map entry is not present in the service establishment message, authentication is assumed to be handled by the transport. These changes should allow the client application launch message to be used with web authentication techniques like OAuth and OpenID as well as with client side certificates when carried over TLS.
- [ogpx] Using the LoginURI as a capability with th… Arrogant Cyberstar
- Re: [ogpx] Using the LoginURI as a capability wit… Infinity Linden (Meadhbh Hamrick)