[ogpx] Service Establishment in OGP

[Infinity Linden <[e-mail]>]

The Open Grid Protocol (OGP) is an open protocol used to carry
information about virtual worlds applications. [1] A key element of
OGP state transitions is the use of HTTP(S) to transport serialized
LLSD dynamic structured data. [2] OGP makes extensive use of
cryptographically unguessable web URLs as capabilities to address
RESTful application resources. [3] Before the client is provided the
address of these capabilities, the client application must
authenticate themselves to the server, demonstrating the client has
authority to access the resource. [4] OGP identifies three modes of
authorization:

	•	authorization following user authentication
	•	authorization following successful negotiation of a TLS session
with a client certificate
	•	authorization following presentation of a recognized OAuth token [5]

Following successful authorization, a capability exposing a RESTful
interface to the server's application state is provided to the client.
The client application may then access the capability as a protocol
endpoint, sending and receiving appropriate data. The process of
authenticating the client, determining if it's authorized and then
granting an appropriate capability is part of the "OGP service
establishment pattern."

Services in OGP

For the most part, OGP does not define "services" as much as it
defines "restful resources". [6] Community input seems to indicate
many participants prefer to group functionally similar resources into
"services." It should be noted however, the use of "resources" as the
fundamental atom of interoperability will likely continue, though
systems that support all the resources defined under a given "service"
may be said to support not only the resources, but that named service
as well. In other words, users of OGP should take special care when
they say they implement a "service" as it implies that they support
each resource defined in that service. Still, collecting resources
into services is a convenient shorthand for describing related
resources. caveat emptor.

Service Establishment

The inputs to service establishment are the URL of a service
establishment protocol endpoint and a credential of some form. The
output is a seed capability from which the client application may
request resources related to the service. Currently defined
credentials include:

	•	a username / password pair
	•	a client certificate recognized by the domain administering the
host serving the service establishment URL
	•	a valid OAuth token

After the client is identified and the request authenticated, the
client is given a seed capability from which it requests further
capabilities.

In Other Words...

The client application needs a collection of capabilities to signal
the server that it wants to do things (like put an avatar in a certain
location or rez an object in the virtual world or send an IM message,
etc.) Capabilities have the feature that they are "portable
authentication tokens" which combine a resource, a permission on a
resource and in many cases the identity of the requester. Possession
of a capability implies permission to access the resource (i.e. - you
don't send a username / password pair with the resource access
request.) Capabilities are unguessable URLs, a portion of which is
randomly generated.

The client application gets these capabilities by sending the "seed
capability" a list of capability names. If the server doesn't know how
about a particular named capability (say it's only a group IM server
and someone tries to ask it for a capability exposing an asset related
service), the server simply ignores that capability name. Also, if a
client application's user
is not authorized to access a certain service, it is again ignored.

The seed capability comes as the result of successful authentication.
The client must provide a valid username / password pair, client
certificate or OAuth token before the server will give it a seed
capability.

Service Establishment with a Username / Password Credential

This is the process currently described in the OGP : Auth document
[4]. It begins with the client posting an agent_login request to a
well known login URL. (note that this URL is properly termed a
"protocol endpoint" instead of a "capability" because it is well
known.) If the client is accessing this URL via HTTPS it SHOULD check
that the server's certificate is valid and trustworthy. OGP does not
define a list of valid root certificates for servers; this is left as
a configuration issue for deployers. Assuming the server certificate
is valid, the client posts the  username / password as described in
the OGP : Auth specification [4]. Assuming everything is in order, the
server returns a seed capability.

Service Establishment with a TLS Certificate

This manner of service establishment is intended to support
communication between different domains. (Remember, a domain is the
administrative authority that controls a collection of hosts.) The
"agent domain" is intended to be a trust broker; that is... on one
side there are a number of users who trust it and on the other is a
collection of service providers who trust it. Users are generally
authenticated by presenting a username and a shared secret (i.e. - a
password.) But two hosts in two different domains need a mechanism to
establish each other's identity. They could distribute a username and
password to each trusted service, but security concerns arise when all
hosts in a given domain are using the same credential and provisioning
a separate username / password pair for each host in a domain is
difficult to manage. The use of X.509 certificate chains provides a
manageable, yet secure alternative. [7]

The trust provided a network peer derives from an X.509 certificate in
the certificate chain presented by the peer. In the case of the
server, the client evaluates the trustworthiness of each certificate
in the server's chain. In the case of the client, the server requests
a client certificate and looks for a trusted certificate in the
client's chain. If either part decides they do not trust the other,
the connection is dropped.

Certificates in TLS frequently come in "chains". That is, the private
key associated with the public key in a trusted root self-signed
certificate is used to sign a subordinate certificate. That
subordinate certificate may be used to sign additional certificates.
In theory, a signing chain can be arbitrarily long, though in practice
short chains are the norm.

An OGP domain wishing to use TLS certificates for authentication must
first generate a "root certificate". Each peer domain that wishes to
interoperate must provide the original domain with a certificate
signing request (which includes the peer domain's identity and it's
public key.) Assuming the original domain trusts the peer domain, it
will sign the peer domain's public key and identity and provide the
peer with a signed peer-domain certificate. The peer domain may then
use the private key associated with the public key in it's peer-domain
certificate to sign server certificates for each of it's hosts.

Before trusting the peer, the consumer of the certificate chain
verifies that each of the following statements are true:

	•	the top most certificate our domain's root
	•	the next certificate in the chain has been issued to a trusted peer
	•	(for clients) the subject name in the bottom certificate of the
chain correctly identifies the server
	•	(for servers) the public key in the bottom certificate of the chain
correctly verifies the client as described in the ClientVerify section
of the TLS specification [8]

Service Establishment with an OAuth Token

OAuth is an emerging system used for authorization across domains. [9]
OAuth is appropriate in the OGP context when a host in one domain must
access a resource maintained in another. OAuth produces a request
specific token the peer may use to verify a requests authorization
without requiring the user's password. This is especially important
when accessing resources on systems which do not have an established
trust relationship. OAuth may be used in conjunction TLS; the OAuth
component is used to verify the user's intent while the TLS
certificate chain establishes the trust between domains.

The OAuth protocol concludes with a distant peer in possession of a
verifiable token used to demonstrate the user's intent. In OGP service
establishment, the protocol endpoint for this interaction is a well
known public endpoint used to authenticate OAuth tokens and return a
seed capability.

Conclusion

Establishing an authenticated, authorized connection between a client
and a server can be accomplished with several methods, depending on
context.

1. Open Grid Protocol : Introduction and Requirements (
http://tools.ietf.org/html/draft-hamrick-ogp-auth-00  )
2. LLSD Abstract Type System (
http://www.ietf.org/internet-drafts/draft-hamrick-llsd-00.txt )
3. Open Grid Protocol : Foundation, Section 2.3 (
http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt )
4. Open Grid Protocol : Authentication (
http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 )
5. OAuth Core ( http://tools.ietf.org/html/draft-hammer-oauth-02 )
6. Architectural Styles and the Design of Network-based Software
Architectures (
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm )
7. Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile (
http://www.ietf.org/rfc/rfc5280.txt )
8. The Transport Layer Security (TLS) Protocol Version 1.2 (
http://tools.ietf.org/html/rfc5246#section-7.4.8 )
9. The OAuth Core Protocol ( http://tools.ietf.org/html/draft-hammer-oauth-02 )