Open ID : Relying Party

A relying party (RP) is a web site or application that wants to verify the end-user’s identifier.

A end-user interacts with relying party. If RP has option to log In with OpenID for authentication and end-user has account with Open ID provider, then end-user provides his OpenID at RP.
For Example: Open ID :
and Open ID provider is :

OpenID Provider URL Discovery:
On basis of provided Open ID, RP discovers Open ID providers URL for further interaction with it.
1)HTML discovery
2)XRDS discovery(eXtensible Resource Descriptor Sequence)

1.The RP converts provided OpenID into a canonical URL format (e.g.

a)With OpenID 1.0, RP performs HTML discovery.
1)RP sends GET or HEAD HTTP request to URL created on basis of given OpenID.
2)RP reads an HTML link tag from HTML Response. Link tag contains URL of Open ID provider

b)With OpenID 2.0, RP performs XRDS discovery.
1) RP sends GET or HEAD HTTP request to URL created on basis of given OpenID and request XRDS document.
2) IF RP sending GET request then Accept header is set to “application/xrds+xml”.
3) RP reads XRDS document from response for endpoint URL of OpenID.

There are two modes in which the relying party may communicate with the OpenID provider:

Relying party requests that the OpenID provider not interact with the end-user. All communication is relayed through the end-user’s user-agent without explicitly notifying the end-user. The checkid_immediate mode may fail if operations cannot be automated. In this case checkid_setup is used.

End-user communicates with the OpenID provider via the same user-agent used to access the relying party.

Relying Party and Open ID provider may establish a shared secret in association then RP redirects end-user’s user-agent to the OpenID provider for authentication with OpenID provider.

Open ID provider requests user to trust RP, Where user either accept or decline it.
1) If the user declines it then user-agent is redirected back to the RP indicating authentication was rejected.
2) If the user accepts it, then the user-agent is redirected back to the relying party along with the end-user’s credentials.

Then RP must then confirm that the credentials really came from the OpenID provider.

Stateful RP:
If the RP and OP has established association previously then they have shared secret. Stateful RP stores such shared secret.
To varify OpenID provider, RP compares shared secret with one received along with the end-user’s credentials.

Stateless RP:
To verify Open ID provider, Stateless RP hits check_authentication request.

After Open ID provider’s verification, authentication process gets completed and user get logged in at RP site.


Request parameters:
RP sends HTTP POST request to OP.

(required) Interaction mode. Specifies whether Open ID provider may interact with the user to determine the outcome of the request. Valid values are:
“checkid_immediate” (No interaction allowed)
“checkid_setup” (Interaction allowed)

(required)Protocol Version

(required)Return URL

(optional) Association handle. Set if an association was established between the relying party and the identity provider

(optional) Claimed identifier of user. This value must be set to “”

(optional) Alternate identifier. This value must be set to “”.

(optional) Authenticated realm. Identifies the domain that the end user is being asked to trust. (Example: “http://*”) This value must be consistent with the domain defined in openid.return_to. If this parameter is not defined, Open ID provider will use the URL referenced inopenid.return_to.

PAPE extension:

(required) Identifies the extension protocol being used. This value should be “”.

(optional) Sets the maximum acceptable time (in seconds) since the user last authenticated. If the session is older, the user will be prompted to log in again. Setting the value to zero will force a password reprompt regardless of session age.

User interface extension:

(required) Indicates that the OpenID provider’s authentication pages will be displayed in an alternative user interface This parameter must be set to “”.

(optional) Specifies the alternative user interface. The following values are valid:
“x-has-session” (used to indicate the presence of an authenticated session)
Additional modes may be supported in the future.
(optional) Displays the favicon of the referring domain in the OpenID approval page if set to “true”.

Attribute exchange extension:
(required) Indicates request for user attribute information. This value must be set to “”.
(required) This value must be set to “fetch_request”.
(required) Specifies the attribute being requested. Valid values include:
To request multiple attributes, set this parameter to a comma-delimited list of attributes.
(optional) Requests the user’s home country. This value must be set to “”.
(optional) Requests the user’s gmail address. This value must be set to either “” or “”.
(optional) Requests the user’s first name. This value must be set to “”.
(optional) Requests the user’s preferred language. This value must be set to “”.
(optional) Requests the user’s last name. This value must be set to “”.

OAuth extension:

(required) Indicates request for an OAuth token. This value must be set to “”

(required) Consumer key provided by Open ID Provider after registering the site. This is typically a DNS domain name. Must be consistent with the value for realm (for example, realm = “” and ext2.consumer = “”, or realm = “http://*” and ext2.consumer = “”).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s