[ogpx] Using the LoginURI as a capability with the Client Application Launch Message

[Arrogant Cyberstar <[e-mail]>]

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.