Difference between revisions of "User:Infinity Linden/OGP Trust Phase 0"

From Second Life Wiki
Jump to navigation Jump to search
Line 12: Line 12:
'''note:''' this diagram needs a bit of an update. it does a poor job describing how capabilities are trusted and it doesn't describe how client applications trust the region domain servers.
'''note:''' this diagram needs a bit of an update. it does a poor job describing how capabilities are trusted and it doesn't describe how client applications trust the region domain servers.


==Authenticating Client Applications to Agent Domain Servers==
==Authenticating Client Application Users to Agent Domain Servers==
 
Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the [[OGP_Authentication_Draft_3|authentication section of the OGP specification]]. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the [[Open_Grid_Public_Beta/Open_Grid_Beta_Viewers|Open Grid Beta Viewers page]].
 
Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the <code>--loginuri</code> option on the command line when invoking the viewer.
 
The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.
 
Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.
 
It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.
 
So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.
 
==Authenticating Client Applications to Region Domain Servers==
==Authenticating Client Applications to Region Domain Servers==
==Authenticating Agent Domain Servers to Region Domain Servers==
==Authenticating Agent Domain Servers to Region Domain Servers==

Revision as of 13:02, 12 September 2008

Important Note

  • This page describes the near term "trust objectives". In this context, "Near Term" means issues relating to features that already existed in Second Life in September 2008, and how they will be implemented to support non-Linden Agent and Region domains. Discussions regarding the future of Trust in OGP (including, but not limited to: Rights Expression Languages, revised permissions for in-world objects, distributed third-party authentication, integrating OpenID or SAML, etc.) should be directed towards the OGP Trust Model page.

Introduction

todo: add introduction here. best done after the content is produced.

How We Authenticate Protocol Actors

simplified trust model

The diagram to the right shows how different protocol actors in OGP establish trust. The diagram shows the three major classes of protocol actors: client applications, agent domains and region domains. The objective of this section is to describe how actors establish trust in remote protocol participants. The concept of "trust" is intimately related to the authentication technology used by client and server software, but can be seen to be more than simple authentication. As we'll see in the section describing the proposed registration authority, authentication "reflects" trust, it does not create it.

note: this diagram needs a bit of an update. it does a poor job describing how capabilities are trusted and it doesn't describe how client applications trust the region domain servers.

Authenticating Client Application Users to Agent Domain Servers

Before an end user may enter the virtual world, they must authenticate themselves. This is just as true for automated systems as it is for human users. Three authentication techniques are described in the authentication section of the OGP specification. When this document was written, only the hashed password authenticator was deployed on the OGP beta grid. It is also thought that for the "near term", Challenge Response and PKCS#5 PBKDF authenticators will not be deployed. It is important to note that the Second Life main grid and canonical Second Life viewer do not implement OGP at this time. Users will need to download the Open Grid Viewer from the Open Grid Beta Viewers page.

Authentication begins with the user providing their password to the client application. The client application in turn constructs an agent_login message that it sends to the agent domain's LoginURI. The LoginURI for Linden Lab's OGP Beta is predefined as the default in the Open Grid Viewer. Users wishing to use a different Agent Domain may use the --loginuri option on the command line when invoking the viewer.

The details of how an avatar or account name and password are established between the end user and the agent domain is beyond the scope of this document. Linden Lab provides a web resource for account creation end users may access via a traditional web browser. Before Linden Lab will create an account, the end user must agree to a Terms of Service document and view any outstanding Critical Messages. Account Creation interactions take place over a HTTPS TLS-Encrypted transport. This is to ensure that eavesdroppers have a limited opportunity to intercept the new user's password.

Other Agent Domain operators are free to implement any policy they wish with respect to the security of agent credentials. But it should be noted that the use of HTTPS to transport agent_login requests is STRONGLY RECOMMENDED. Services deployed by Linden Lab will refuse to to agent_login requests that do not use HTTPS. As described later in this document, Linden Lab region domains may reject protocol messages from agent domains that do not require the use HTTPS for username/password establishment or for agent_login requests.

It is also important to note that the Open Grid Beta Viewer from Linden Lab will refuse to attempt to connect to non-https LoginURI. Agent domain operators who do not wish to use HTTPS based LoginURIs will need to distribute their own viewer application.

So... to recap. End users authenticate themselves to agent domains by using a username / password pair. How an agent domain establishes the trustworthiness of the end user is beyond the scope of this document. HTTPS is your friend. Linden Lab's servers may snub you if you don't like HTTPS.

Authenticating Client Applications to Region Domain Servers

Authenticating Agent Domain Servers to Region Domain Servers

Authenticating Region Domain Servers to the Agent Domain

Specific Issues With Linden Lab Software

Linden Lab Self Signed Certificate For Agent and Region Domain Authentication

Specific Issues With OpenSim Software

Self Signed Certificates for Agent and Region Domain Authentication

Proposed Registration Authority for OpenSim Operators

Specific Issues With PyOGP Software

Note: Tao... Sai... I know we discussed this a bit... but i'm blanking on what we said... so feel free to add stuff here, otherwise i'm going to add my best guess regarding how we want to handle it

Discussions