ExtremeSwank

Auto-Logon for OpenID Providers Specification 1.0 Draft 1

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.

User Agent:

The application that provides access to services for the User.

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.

2. Overview

This is a brief specification that provides a framework for OpenID Providers to support authentication by automated means. This framework does not provide any functional changes to the OpenID protocol, but should be used by any Extension specifications that require automatic authentication with an OpenID Provider.

The following specifications are known to implement this specification:

3. Theory of Operation

There are some conditions where it is not feasible for a traditional OpenID User Agent (i.e., a Web Browser) to authenticate with an OpenID Provider. In these conditions, a standard for passing automated credentials is necessary. The following protocol flow is expected:

1. User Agent discovers the OpenID Provider service end-point, per the OpenID Specification
2. User Agent performs a simple GET request to the discovered service endpoint and retrieves an authentication salt value that will be used to generate a login credential
3. User Agent combines the the received salt value with the user’s service crendential (a password, or other secret value) and generates a login credential.
4. User Agent performs a normal OpenID authentication (“checkid_immediate”) request, passing the login credential as extension arguments
5. OpenID Provider returns a standard authentication response to the User Agent via HTTP Redirect or HTTP POST (“id_res”)

4. Protocol Details

4.1. Standard Authentication Challenge

The OpenID Provider MUST supply the following headers in the HTTP response to the User Agent:

X-OPENID-AuthenticationHash: [HASHCODE]

X-OPENID-AuthenticationExtensions: [URIs]

Where [HASHCODE] is a Base64-encoded random value will be used to generate a hash of the Authentication Credential. 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. The exact use of this value MUST be specified in any specification which inherits this specification.

Where [URIs] is a space-delimited list of the Extension namespaces that are supported for automated authentication. For each Extension supporting automated authentication with the OpenID Provider, the namespace URI MUST be specified here. Each specification that inherits from this specification MUST state its namespace URI, and MUST expect its URI to be present in order to proceed with authentication.

4.2. User Agent Authentication Response

The User Agent will respond to the authentication challenge with a standard OpenID authentication request, with the following additional arguments:

openid.ns.autologon

Value: “http://extremeswank.com/specs/autologon-1.0”

openid.autologon.credential

Value: An SHA-512 hash of the concatenation of the authentication hash provided in the authentication challenge and the key crendential expected by the inheriting specification.

4.3. Expected OpenID Provider Behavior

After the authentication request has been submitted, the OpenID Provider MUST immediately return a response consistent with an OpenID Immediate authentication request.

5. References

5.1. Normative References

Comments