4.2.5. Requesting Identity Authentication

Once you know the OP endpoint, or also the claimed identifier and internal identifier, your application sends an identity authentication request using the user’s browser redirection. The request includes special parameters for its realization. These parameters are listed in the message’s body using their identifiers. Design of this identity authentication request are again directly carried out by OpenID libraries you will use for the implementation.

Identity authentication request usually includes the following parameters:

  • Return address of the service provider’s application – The address to which the user returns after logging in from the OpenID provider’s website and where the outcome of the login is processed in your application.

  • Service provider’s URL realm (hereinafter as realm) – defines the part of a URL region for which the identity authentication request is valid. The service provider’s return address must lie in this URL region. The XRDS document or an information about this position must be available at this address.

  • Choice of the required login method – the choice is done by placing the identifier of the given login method into the identity authentication request. The mojeID service does not only supports the common login by password, but also login by a digital certificate or a one-time password (OTP).

    • Login using certificate can be requested via PAPE extension using the following identifier:
      http://schemas.openid.net/pape/policies/2007/06/phishing-resistant

      When logging in using a certificate, the following messages are displayed:
      “Poskytovatel služby požaduje přihlášení certifikátem.”
      “The service provider wants you to login with your certificate.”

    • Login using one-time password or the MojeID Authenticator application can be requested using the following identifier:
      http://schemas.openid.net/pape/policies/2007/06/multi-factor

      When logging in using a one-time password, the following messages are displayed:
      “Poskytovatel služby požaduje přihlášení jednorázovým heslem nebo MojeID Autentikátorem.”
      “The service provider wants you to login with one time password or MojeID Autentikátor.”

    • Login using a security key can be requested using an identifier:
      http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

    When logging in using a security key, the following messages are displayed:
    “Poskytovatel služby požaduje přihlášení druhým faktorem.”
    “The service provider wants you to login with two-factor authentication.”

  • Limiting the user’s login period – if the user logs in successfully, the mojeID system keeps this user “logged in”. If the user logs in to another service provider during this period, they do not have to authenticate on the mojeID login page. However, you can limit your identity authentication request for any period since the last authentication if you consider it necessary, e.g. because of security. This choice can be requested using the max_auth_age field of the PAPE extension. If the user has not logged in to mojeID in the last max_auth_age seconds, he needs to log in again.

  • User’s claimed identifier to be verified – The identity name corresponding to this claimed identifier will be displayed to the user on the mojeID login page. If the user chooses the identifier from OP, it contains a special value.

  • Required data from mojeID identity – identity authentication request can also include a list of individual data from mojeID identity which your application requires and which are handed over to your application with the user’s consent after a successful login. For each piece of data, its identifier needs to be presented. MojeID supports requesting the following data (details and formats of the individual items can be found at the address of the identifier of the piece of data, some of them – name, nickname, e-mail. date of birth, postal code, and country – can be retrieved using a simpler identifier of the SReg extension). The list of possible data can be found in the Appendix 2 – List of Data to be Handed Over (OpenID 2.0).

Examples of items that can be included in the identity authentication request are listed in the following table:

Parameter (key)

Description (value)

openid.ns

Determining the used OpenID protocol.
http://specs.openid.net/auth/2.0

openid.claimed_id

User’s claimed identifier.
http://demo.mojeid.cz/

openid.identity

User’s internal identifier.
http://mojeid.cz/id/unique_string/

openid.assoc_handle

Identyfing string of a previously established association.
{HMAC-SHA256}{4c486ac3}{Ze6JZA==}

openid.return_to

Return address from mojeID. In older OpenID protocol specifications, this field is called openid.trust_root.
http://www.provider-example.cz/MojeID-Return.html

openid.realm

Service provider’s URL region.
http://www.provider-example.cz/

openid.ns.ax

Choosing an extension for attribute exchange. The “ax” string can have any other name your library chooses. Here it is only stated how it will be linked from now on.
http://openid.net/srv/ax/1.0

openid.ax.mode

Attribute exchange mode (receiving, storing).
fetch_request

openid.ax.type.firstName

Requesting an attribute; there can be any attribute instead of firstName řetězec.
http://axschema.org/namePerson/first

openid.ax.type.validated

Another attribute – this time information about user’s data verification.
http://specs.nic.cz/attr/contact/valid

openid.ax.type.jabber

http://axschema.org/contact/IM/Jabber

openid.ax.required

A list of attributes about which the service provider claims they are essential for proper account creation/update, or rather for the service provider’s application operation itself (required items).
firstName,validated

openid.ax.if_available

A list of extra attributes (optional items). The service provider wants them, but it is ok if he does not get them.
Jabber

openid.ns.pape

Choosing an extension for authentication policies.
http://specs.openid.net/extensions/pape/1.0

openid.pape.max_auth_age

Number of seconds since the last authentication. If the user did not authenticate during this period, they have to authenticate again.
3600

openid.pape .preferred_auth_policies

A space-separated list of identifiers of the required policies.
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant