ExtremeSwank

Trusted Authentication Extension 1.0 Draft 8

Informal Overview

Let’s say I have an OpenID (extremeswank.com). I am paying for a software service at two websites: basecamphq.com and simplepaystubs.com. I log in to both sites regularly using my OpenID.

I want to be able to automatically transfer my time information from my account at basecamphq.com to my account at simplepaystubs.com. simplepaystubs.com, because it supports the Trusted Authentication Extension, offers the ability to log in to my account at basecamphq.com, and transfer the information automatically.

I go to the config page and supply the OpenID I use at basecamphq.com in the “Link my account to Basecamp” field.
simplepaystubs.com does a OpenID discovery, finds my OpenID Provider, and forwards me over to my OpenID Provider along with a request to get a Trusted Authentication key.
At my OpenID Provider, I am asked if I want simplepaystubs.com to access my account at basecamphq.com. I say yes, and am redirected back to simplepaystubs.com with a special authentication key included.
At this point, simplepaystubs.com has a special key that it can use to log in to my account at basecamphq.com.

From then on, any time simplepaystubs.com needs data from basecamphq.com, it can log in automatically. Here’s what is basically does behind the scenes:

simplepaystubs.com wants to log into my account at basecamphq.com to get some data.
simplepaystubs.com connects to basecamphq.com’s login page, and submits the OpenID to the form.
basecamphq.com redirects simplepaystubs.com to my OpenID provider.
When prompted with the login page, simplepaystubs.com will pass special arguments, including a hash of the authentication key that it got previously from the OpenID Provider.
The OpenID Provider verifies that the key is valid for this connection, and either approves or disapproves. In this case, the OpenID Provider approves, and simplepaystubs.com is forwarded back to basecamphq.com with a positive assertion, meaning the login was successful.
simplepaystubs.com is now logged in, and since it knows all about how basecamphq.com works, it does its magic to retrieve the required data.

Everything, except specifying the OpenID and approving the connection, is done automatically, and requires no additional attention from me.

1. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

1.1. Definitions and Conventions

User:

Also referred to as “End User” or “Subject”. A person with a digital identity who participates in OpenID-based identity information exchanges using their client software, typically a web browser.

OpenID Provider:

Also called “OP” or “Server”. An OpenID Authentication server on which a Relying Party relies for an assertion that the end user controls an Identifier.

Relying Party:

Also called “RP” or “Consumer”. A Web application that wants proof that the end user controls an Identifier.

Client Consumer

The OpenID Consumer that is requesting authentication access to data protected by the Destination Consumer.

Destination Consumer

The OpenID Consumer which is protecting access to data requested by the Client Consumer.

All OpenID Trusted Authentication messages MUST contain the following extension namespace declaration, as specified in the Extensions section of OpenID-Authentication-2.0:

openid.ns.<extension_alias>=http://extremeswank.com/specs/trustedauth/1.0

The actual extension namespace alias should be determined on a per-message basis by the party composing the messages, in such a manner as to avoid conflicts between multiple extensions. For the purposes of this document, the extension namespace alias for the Trusted Authentication service will be “trustedauth”.

2. Overview

The Trusted Authentication Extension is identified by the URI “http://extremeswank.com/specs/trustedauth/1.0” [NOTE: subject to change in following drafts]. This URI MUST be specified in the extension namespace declaration.

This extension is intended to fill the need for giving a site permission to access data stored at another site using a user’s OpenID. This is said to be “trusted”, because only the initial trust action is required to configure the requesting site (Client Consumer) to access the target site (Destination Consumer). From that point forward, the Client Consumer can access the Destination Consumer without user intervention.

This specification must be implemented by both the Client Consumer and the OpenID Provider. This system only provides the authentication framework, and does not specify how the user data should be exchanged between sites.

SSL must be used to exchange the authentication key, which is passed through the User Agent. For OPs that do not support this extension, the request will be handled like a normal OpenID authentication request.

The request parameters detailed here MUST be sent using the [OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 – Draft 11,” January 2007.) extension mechanism.

3. Discovery

Discovery of the Trusted Authentication extension is achieved via the mechanism described in [OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 – Draft 11,” January 2007.). The Trusted Authentication namespace “http://extremeswank.com/specs/trustedauth/1.0” SHOULD be listed as an <xrd:Type> child element of the <xrd:Service> element in the XRDS discovery document.

4. Theory of Operation

The Trusted Authentication extension is based on the concept of “trusted connections”. A trusted connection gives one site permission to access the resources on another specific site, for a specific user account at that site.

Trusted connections are stored and managed at the OpenID Provider. A Consumer that wants access to an account at another site (the Client Consumer) will ask the OpenID Provider for permission to do so. If the request is approved by the user, the OpenID Provider will provide an authentication key (the shared secret) to this Consumer.

The shared secret is used whenever the Client Consumer wants to log in to the other site (the Destination Consumer). When prompted for credentials by the OpenID Provider, the Client Consumer will simply submit a hash of the authentication key to the OpenID Provider. The OpenID Provider will then approve the authentication request, and the Client Consumer will be logged in successfully to the Destination Consumer.

The OpenID Provider SHOULD provide the ability for the owner of the Identity to cancel or revoke any stored connection credentials. This will result in giving the user more control over their online security.

4.1. Creating a trusted connection

In this case, the Client Consumer will be acting as an OpenID Relying Party

User provides an Identifier to the Client Consumer, with the full intent of establishing a trusted connection
Client Consumer performs a normal “checkid_setup” authentication request with the OpenID Provider, with itself as the “return_to” location
The User Agent is redirected to the user’s OpenID Provider
User is prompted to confirm authorization to create a trusted connection so the Client Consumer can log in to the Destination Consumer
OpenID Provider generates a shared secret, which it stores to verify any future authentication requests
OpenID Provider redirects the User Agent to the Client Consumer with the shared secret as an argument
Client Consumer stores the shared secret, which it will use any time it wants to log in to the Destination Consumer as that user

4.2. Logging in using a trusted connection

In this case, the Client Consumer will be acting as an OpenID User Agent.

Client Consumer connects to the Destination Consumer and provides an OpenID for logon purposes
Destination Consumer performs a normal “checkid_setup” authentication request with the OpenID Provider, which, per OpenID protocol, the Client Consumer is redirected to the OpenID Provider
OpenID Provider presents the Client Consumer with an authentication challenge
Client Consumer submits a SHA-256 hash of the shared secret to the OpenID Provider in response
OpenID Provider verifies the hash, continues processing the “checkid_setup” request, and sends and authentication response.
Destination Consumer verifies that the information received from the OpenID Provider (through the Client Consumer) is valid
Client Consumer is now logged into the end-user’s account at the destination site

5. Request and Retrieval of Trusted Credentials

5.1. Request for Trusted Credentials

The Client Consumer will perform a normal “checkid_setup” request with the OpenID Provider, and supply the following additional arguments:

openid.ns.trustedauth

Value: “http://extremeswank.com/specs/trustedauth/1.0”

openid.trustedauth.mode

Value: “key_req”

openid.trustedauth.sourcename

Value: The name of requesting application
Example: ThisHost.com

openid.trustedauth.dest

Value: The login URL for the site
Example: http://www.destinationsite.com/openid_login.php

Note: The openid.return_to URL must be an HTTPS URL. If it is not, the OpenID Provider MUST immediately reject the request by returning a “openid.trustedauth.verified=false” response.

5.2. Trusted Credential Response from OP

The OpenID Provider will provide a normal “id_res” response to the authentication request, and include the following additional arguments:

openid.ns.trustedauth

Value: “http://extremeswank.com/specs/trustedauth/1.0”

openid.trustedauth.mode

Value: “key_res”

openid.trustedauth.verified

Value: true if successful, false if not. If this argument is not present, the Client Consumer MUST assume that the OpenID Provider does not support this extension.

openid.trustedauth.dest

Value: http://www.destinationsite.com/openid_login.php

openid.trustedauth.secret

Value: The shared secret in BASE64 format. MUST return a blank value if openid.trustedauth.verified is false.

6. Utilizing Trusted Credentials

6.1. Passing the identifier to the Destination Consumer

Client Consumer provides identifier to destination consumer per OpenID Authentication specification. Passing this identifier is out of the scope of this specification.

6.2. Redirecting to the OP

The Destination Consumer will initiate a normal “checkid_setup” request with the OpenID Provider. The Client Consumer will act as the User Agent. OpenID Provider MUST provide the following HTTP header in its response to the Client Consumer:

X-OPENID-AuthenticationHash: [HASHCODE]

X-OPENID-AuthenticationSupported: [URIs]

Where [HASHCODE] is a Base64-encoded random value that can optionally be used to generate a SHA-256 hash of the verification key. The OpenID Provider should cache this value for a short period (less than 60 seconds), and expire the value once an authentication request has been submitted using that value. This is intended to protect against replay attacks.

Where [URIs] is a space-delimited list of the Extension namespaces that are supported for automated authentication. The namespace of this Extension must be present in the list. If the namespace URI is not present, the Client Consumer MUST assume that the OpenID Provider does not support this extension.

6.3. Passing credentials to the OpenID Provider

Client Consumer will submit the following arguments to the current URL at the OpenID Provider, being sure to include any pre-existing Query String arguments:

openid.ns.trustedauth

Value: “http://extremeswank.com/specs/trustedauth/1.0”

openid.trustedauth.mode

Value: “proxyauth”

openid.trustedauth.hashcode

Value: Verbatim, the hashcode received from the OpenID Provider

openid.trustedauth.secret_hash

Value: SHA-256 hash of the shared secret and the hashcode

6.4. Authentication Request Completion

The OpenID Provider will provide a normal “id_res” response to the authentication request, and include the following additional arguments:

openid.ns.trustedauth

Value: “http://extremeswank.com/specs/trustedauth/1.0”

openid.trustedauth.mode

Value: “proxyauth”
Note: This is a courtesy notification to the Destination Consumer that this authentication request is a trusted connection, and not a request directly requested by an end-user.

7. Security Considerations

Please take the following security notes into account:

The OpenID Provider must ensure the trusted connections only allow access to a specific account at a specific site. A Provider MUST NOT allow the same shared secret to be used to log in to multiple user accounts or destination sites.

When being granted a shared secret for a trusted connection, communication between the OpenID Provider and the Client Consumer must be secured with SSL. The shared secret is transmitted through the User Agent. Therefore two things must occur:
- The User Agent MUST already have an SSL connection to the OpenID Provider when the OpenID Provider redirects the User Agent back to the Client Consumer
- The User Agent MUST ensure that the redirect to the Client Consumer is to a HTTPS URL

OpenID Trusted Authentication is an OpenID extension, and thus uses OpenID Authentication request and response messages for exchanging data.
- See the “Security Considerations” section of [OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 – Draft 11,” January 2007.).

8. References

8.1. Normative References

[OpenID.authentication-2.0]	Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 – Draft 11,” January 2007 (TXT, HTML).
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).

Comments

No one has written any comments for this page. Use the form to add your comments.