Skip to main content
This is similar to the standard use case delivered by the Recover ID Process, except the end user has more than one registered, verified authentication identifier (authN ID). An anonymous end user selects to recover their identity using a registered authN ID (email or mobile). In this use case, the end user actually has more than one registered and verified authN ID. Therefore, once they submit one of their authN IDs to show who they are, the Process will then return a list of obfuscated authN IDs, and request for the end user to specify where they want the reset action token to be sent.

Initial Request

Your client calls the Process Start API to initialize the Process:

Response

Digital Identity Management responds with a request to provide a registered (and verified) email or mobile:

Next Request: User’s AuthN ID

Your client calls the Process Step API, and passes the user-supplied authN ID to the Process:

Response: Specify destination AuthN ID

Digital Identity Management looks up the User entity and determines that they have two or more verified contact channels registered as authN IDs on the User entity. The Process returns a list of obfuscated authN IDs and requests the end user to select which destination to which they want the recovery message sent:
The recoveryOptions object should be used to display possible options to the user. The object is formatted in a key/value pairing, where the key is the index of the recovery option, and the value is the Authentication Identifier correspondent to the recovery option, which the user can identify.

Final Request

When the end user selects a destination, your client provides the index selection (from the previous Process response) to Digital Identity Management in the PUT /process/step API:

Process Complete

Digital Identity Management issues an action token, and ends it to the contact channel specified by the end user. The Process ends, and returns a 200 HTTP status:
OTP Verification & Resend Verification Any Process step that sends a Digital Identity Management action token to a user also returns a corresponding PKAT to the client application. In order to enable OTP verification on the UI, the client must retain the PKAT returned by the final Process step. The PKAT, along with the user-supplied OTP, is required for the [GET /session/token?customToken=\{OTP\}&pkat=\{pkat\}](c_sessionToken#) API to invoke the subsequent Activate User Process to complete the user onboarding. In cases where the user is anonymous, the PKAT is required if the application wants to provide a quick token resend option on the UI, using the [PUT /session/token?pkat=\{pkat\}](c_putSessionToken) API. This method applies to cases where the user is anonymous (i.e., they are not authenticated in Digital Identity Management). However, if the user is currently authenticated in Digital Identity Management, the client application can instead invoke the Resend Verification Process for this purpose. Parent topic:Recover ID & Reset Password Processes