1.3 Overview
The Passport SSI Version 1.4 Protocol, also known as the "Passport Tweener" Protocol, is an HTTP-based protocol (as specified in [RFC2616]) for authenticating a client to a partner server with the assistance of an authentication server. The authentication exchange between the client and the partner server in the Passport SSI Version 1.4 Protocol resembles the exchanges in other HTTP authentication mechanisms (as specified in [RFC2616] and [RFC2617]).
When a client makes an HTTP request to the partner server, the partner server might respond with a Passport SSI Version 1.4 Protocol message (as specified in section 2.2.8) indicating that the URL requires Passport SSI Version 1.4 Protocol authentication. The client then contacts the authentication server (as specified in section 2.2.10) to obtain a partner token that authenticates the user to the partner server, and then retries the HTTP request, this time attaching the partner token (as specified in section 2.2.6).
If this authentication fails, the partner indicates failure and restates that Passport SSI Version 1.4 Protocol authentication is required. If authentication succeeds, the partner responds with the content that required authentication, along with the same partner token (as specified in section 2.2.9) in HTTP cookie form, using the HTTP cookie mechanism (as specified in [RFC2109]). The client thereby automatically resends the cookie-encoded token to the partner server every time it returns to the partner server.
When the client contacts the authentication server in response to a partner server's request for authentication, the client provides credentials (that is, a user name and password; for more information, see section 2.2.7). The authentication server verifies the credentials and, if they are valid, supplies the client with a partner token (opaque to the client) that can be used to authenticate to the partner server (as specified in section 2.2.11). The authentication server also supplies the client with an authentication token in HTTP cookie form (as previously described) so that on subsequent visits to the authentication server to obtain partner tokens for other partner servers, the authentication server can automatically retrieve the user's authentication information based on the accompanying cookie, instead of requiring the client to resend the actual credentials every time.
The client can delete its tokens or cookies at any time. One point of departure from the traditional HTTP framework is that the authentication server can instruct the client to delete an authentication token it previously obtained (as specified in section 2.2.4). In this case, the client deletes the authentication token.
The Passport SSI Version 1.4 Protocol allows for the implementation of distributed authentication servers by allowing an authentication server to redirect clients to an alternate authentication server using an HTTP redirect response (as specified in section 2.2.5). The protocol also supports multiple independent realms in which each realm consists of an authentication server (single or distributed) capable of helping a specific set of users authenticate to a specific set of partner servers. A user's credentials are stored at the authentication server for a specific realm, which in turn allows that user to authenticate to any of the set of partner servers associated with that realm.
Each realm also has a configuration server, which provides the client with information on the authentication server for that realm, such as its URL. A client is initially configured with the URL of the configuration server for some realm. This can occur, for example, when the user enrolls in or joins a realm. If the client has no configuration data, or if its configuration data is out of date, the authentication server can provide an up-to-date configuration version number to the client any time the client authenticates (as specified in section 2.2.3). The client issues a standard HTTP GET request to the configuration server's URL to obtain updated configuration information. For more information, see section 3.1.5.3.