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].
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.
Client Application:
An application that combines the functionality of both the User Agent and the Relying Party, and cannot direct a user to a Web Site for authentication. This applies to most interactive (Telnet/SSH) applications.
All OpenID Inline 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/inlineauth/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 Inline Authentication service will be “inlineauth”.
The Inline Authentication Extension is identified by the URI “http://extremeswank.com/specs/inlineauth/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 providing real-time authentication for interactive services that cannot access a web browser, yet require authentication. This is done through a verification key, which is provided by an OpenID Provider. The user will provide this key to the Client Application through manual input. The Client Application then verifies the validity of the key with the OpenID Provider.
A key target for this specification would be an interactive service operating over Telnet, or an interactive desktop application.
This specification must be implemented by both the Client Application and the OpenID Provider.
The request parameters detailed here MUST be sent using the [OpenID.authentication-2.0] extension mechanism.
Discovery of the Inline Authentication extension is achieved via the mechanism described in [OpenID.authentication‑2.0]. The Inline Authentication namespace “http://extremeswank.com/specs/inlineauth/1.0” SHOULD be listed as an <xrd:Type> child element of the <xrd:Service> element in the XRDS discovery document.
The user attempts to log in to an interactive service (such as Telnet), and is prompted for an OpenID Identifier. Once supplied, the user is then prompted for a verification key. The user retrieves their verification key from their OpenID Provider and supplies the verification key to the interactive application. The user is now logged in to the application.
When the user attempts to log on the service and supplies the OpenID Identifier, the Client Application submits an authentication request to the OpenID Provider. The OpenID Provider responds with whether or not this service is supported for this account.
The User then must get a verification key from the OpenID Provider. The method of retrieving this key is out of the scope of this specification, however, some options are e-mail, SMS, Instant Message, an AJAX-enabled website, or a specialized desktop application. Optionally, the user can be in possession of a key-generating authentication token (ex, SecurID) or hardware crypto device that provides those keys on a rotating basis, so the user would not need to be notified of the verification key.
The user is prompted for their verification key, which is typed in and submitted.
The Client Application then connects to the OpenID Provider and submits the verification key. The OpenID provider then responds immediately with an positive or negative assertion.
Behind the scenes, the following is occurring:
In this Extension, the traditional notion of the User Agent, the Relying Party, and the OpenID Provider have changed.
The Client Application will initiate a OpenID authentication request (“checkid_setup”) to the OpenID Provider, with following additional arguments:
openid.ns.inlineauth
Value: “http://extremeswank.com/specs/inlineauth/1.0”
openid.inlineauth.mode
Value: “key_req”
The OpenID Provider will redirect the Client Application to the authentication form URL and MUST supply the following HTTP headers in the response:
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 Application MUST assume that the OpenID Provider does not support this extension.
At this time, the OpenID Provider SHOULD make the verification key available to the end-user.
The Client Application will submit the following arguments to the logon URL at the OpenID Provider, ensuring that all pre-existing Query String arguments are retained:
openid.ns.inlineauth
Value: “http://extremeswank.com/specs/inlineauth/1.0”
openid.inlineauth.mode
Value: “verify_req”
openid.inlineauth.hashcode
Value: Verbatim, the hashcode received in the HTTP response header.
openid.inlineauth.verificationkey
Value: The verification key provided from the OpenID Provider to the end user.
The OpenID Provider, per the OpenID Specification, will attempt to redirect the Client Application to the return_to URL specified in the initial authentication request (the “id_res” response). In cases where an HTTP server does not exist to receive the request, the Client Application MUST NOT follow the redirect, and trap all the arguments in the redirect’s Query String. The Client Application should then verify the validity of the data as if it were the Relying Party receiving the request.
The following additional arguments will be included in the response:
openid.ns.inlineauth
Value: “http://extremeswank.com/specs/inlineauth/1.0”
openid.inlineauth.mode
Value: “verify_res”
Although it is recommended that the verification key be generated for a single use, it is not required. In some cases, it may be desirable for an OpenID Provider to offer the ability to “group” similar sites to share the same common, reusable, verification key. This would emulate the functionality of LDAP or Active Directory, but enable applications to implement the much simpler OpenID protocol. This also has security benefits over LDAP or Active Directory, as the reusable key will not typically be the same as the credential used to log in to the OpenID Provider’s management interface.