Two-Way, Combined Verification Value, ENS System-Default Message Body

An explicit integration level, ENS consumer desires to send an OOB challenge to its recipient user’s mobile phone using a combined verification value (ENS-generated OTP + Consumer-provided, user PIN) and an ENS system-default message body. The consumer elects the ENS provider to verify the recipient’s response to the OOB challenge. The consumer would like to ensure the recipient is given approximately 7 minutes to respond to the OOB challenge with the correct verification value.

Consumer Completed Pre-requites

The consumer has previously completed the following pre-requisites:

• Determined the recipient’s mobile phone number to send in its OOB notification request.
• Determined the user’s PIN value to comprise the second half of the recipient’s combined, final verification value.
• Subscribed to receive ENS enterprise events.

Consumer Use Case Options

This tutorial example applies the following four consumer options:

1. Explicit integration level.
2. Two-way verification.
3. Combined verification value (ENS-generated OTP + Consumer-provided, user PIN).
4. ENS system-default message body.

Steps

1. Consumer presents the recipient OOB challenge instructions from its application user interface:
   • Select which mobile phone number should receive the OOB notification.
   • Press the “Verify Log In” button to trigger the OOB challenge notification.
2. Consumer sends the <OOBValidateRq> notification request to the Enterprise OOB Service provided by ENS.
3. ENS:
   • Validates the consumer’s request.
   • Generates a random 6-digit numeric OTP verification value
   • Returns the <OOBValidateRs> message with the verification value.
   • Returns the ENS–generated OTP in the <OTP> element of the <OOBValidateRs> message.
   • Selects which ENS system-default message body to send based on the request values.
4. ENS:
   • Appends the consumer-provided, PIN verification value to its ENS-generated OTP value to create a combined, final user verification value.
   • Adds a new OOB session for the consumer’s two-way use case.
5. ENS sends the OOB notification as an SMS message to the recipient’s mobile phone.
6. ENS sends a “90040 – ENS Publisher Feedback” enterprise event confirming that the recipient successfully verified the OOB challenge.
7. Consumer receives the enterprise event and confirms successful OOB verification to recipient user.

Flowchart

Example Messages

OOBValidate Request

This request sample below:

• Includes the consumer-provided, user PIN value as the verification value to form the second half of the recipient’s combined, final verification value.
• Specifies the default, “TwoWay” canonical in the <OOBModeType> value for illustrative purposes.
• Specifies an optional OOB session expiration date/time.
• Provides an optional salt value as an additional security measure to the verification value.

<SOAP-ENV:Body>
    <OOBValidateRq xmlns=“http://jackhenry.com/jxchange/TPG/2008”>
        <MsgRqHdr>
            <jXchangeHdr>
                <AuditUsrId>AuditUsrId1</AuditUsrId>
                <AuditWsId>AuditWsId1</AuditWsId>
            </jXchangeHdr>
        </MsgRqHdr>
        <PhoneNum>4175556652</PhoneNum>
        <VerifVal>1234</VerifVal>
        <OOBExpSec>420</OOBExpSec>
        <EncryptVerifValSalt>Ov@t1on0126</EncryptVerifValSalt>
    </OOBValidateRq>
</SOAP-ENV:Body> 

OOBValidate Response

 <SOAP-ENV:Body>
    <OOBValidateRs xmlns=“http://jackhenry.com/jxchange/TPG/2008”>
        <MsgRsHdr>
            <jXchangeHdr>
                <AuditUsrId>AuditUsrId1</AuditUsrId>
                <AuditWsId>AuditWsId1</AuditWsId>
            </jXchangeHdr>
        </MsgRsHdr>
        <AlrtPkgId>4bae69d3-4fe7-484d-96d9-676ece58e522</AlrtPkgId>
        <OTP>824096</OTP>
        <RsStat>Success</RsStat>
    </OOBValidateRs>
</SOAP-ENV:Body>

Referenced and Associated Operations

It is highly recommended that as part of referencing this use case that a user becomes familiar with the following jXchange operations and their function. While the user may elect to not use the listed operation as part of their programming or workflow, knowledge of the operations listed below is essential to understanding the process set forth with this use case.

Detailed information about the operation, the request structure/response, error messages and other useful information can be obtained by clicking the operation name below.