4.2.9. Response Processing

If the message with the response to the identity authentication request is successfully verified, your application can process the data included in the response and finish the process of login via mojeID. The web application must perform this processing at the return address included in the identity authentication request.

4.2.9.1. Login Outcome

When processing the login outcome, it is necessary to take care of the following special situations regarding a successfull login:

  • The user’s first login – if the user who has successfully logged in visits your application for the first time, it is usually necessary that you create an account for them where the data retrieved from the mojeID identity will be stored, plus, of course, also all the other application-specific data. When creating such account, it is recommended to:

    • use the data retrieved from the mojeID identity instead of filling in the registration form, or show the user only such fields that could not be filled with the data retrieved from mojeID

    • and inform the user of the data from mojeID identity that the given application needs and recommend them to allow its transfer upon each login.

  • Repeated login vs. new user login – each time the response is processed the claimed identity of the user must be checked, because two different users might have the same identity name in case one person cancels their mojeID identity (and thus releases their identity name) and another person creates an identity with the same identity name. Such users are then distinguished using a unique string at the end of the claimed identity’s URL.

  • Login of a user who did not requested it directly – your application might receive a response with a successful login even if the user did not request the login directly in your application. It is a situation that should not be considered an error – the login request came from a different website than the one to which the data returns (the protocol does not stores the information about the application that generated the message; if you require such information, you have to add it yourself). However, thanks to the information presented at the mojeID login, the users are always aware to which service they are logging in and to whom they are providing their data.

When processing the login outcome, it is necessary to take care of the following situations regarding an unsuccessfull login:

  • Login request denial – After the user comes to the login page, they can deny the login request, for example because they did not initiated it themselves. Your application then has to take care of this state.

  • Impossibility of immediate authentication – Your application can force identity authentication without a contact with the user. If the OpenID provider is not able to provide such authentication, this type of response is returned which means the classic authentication needs to be performed. Some libraries do not distinguish this state from the previous state.

  • Protocol error – The OpenID provider returns this type of message if it is able to determine your application’s return address but it is not able to distinguish another field of the message because it contains data that contradict the protocol. The OpenID provider returns this type of messages, for example, if he receives a message with an internal identifier he is not able to verify.

4.2.9.2. MojeID Identity Data

If you enquire about the mojeID identity data, it is necessary to take care of the following special situations:

  • User’s repeated login – upon each repeated login of the user using mojeID, it is necessary to check whether the data stored in your application’s internal account match the data retrieved from the user’s mojeID identity upon login. In case they differ, the data in the internal account need to be updated with the data from the mojeID identity, as those are probably up to date.

  • Required data not received – the user always has a chance to choose which data will and will not be handed over to your application upon login. Therefore, it is possible that the application requests certain data, yet it does not receive them due to the user’s choice. It is recommended to take care of this situation and divide the data requested by the application into required data that are essential for the application to work, and optional data that the application does not need. You can then design the application’s operation based on this division.

A special case is the possibility of allowing only the login of fully identified or validated (physically verified) mojeID users. The http://specs.nic.cz/attr/contact/valid and http://specs.nic.cz/attr/contact/status items are handed over every time an application of a provider with full access requests them. The data which the user does not allow to be handed over are returned in the body of the message without a value.