Hybrid Two-Way, ENS Generated OTP Verification

An ENS publisher desires to send an OOB challenge using either recipient user’s mobile phone or e-mail address using an ENS-generated OTP verification value.

• If the recipient responds to the OOB challenge using their mobile phone contact point, then the publisher elects the ENS provider to verify the recipient’s response to the OOB challenge.
• If the recipient responds to the OOB challenge using their e-mail contact point, then the publisher elects to verify the recipient’s response to the OOB challenge in its own application user interface.

Publisher Completed Pre-requites

The publisher has previously completed the following pre-requisites:

• Deployed its “Unknown User OOB Alert” notification to ENS.
• Added the recipient and subscription information in ENS, which includes:
  • The recipient and subscription information records.
  • Recipient’s “Mobile number” and “E-mail address” contact ID’s and contact points in the recipient record.
  • Contact ID’s assigned for respective SMS and e-mail channels in the subscription to the notification.
• Subscribed to receive ENS enterprise events.

Publisher Use Case Options

This tutorial example applies the following four publisher options:

1. Recipient-subscription integration level.
2. Two-way or one-way verification for SMS notification. One-way verification for e-mail notification.
3. ENS-generated verification value.
4. Published notification message bodies.

Steps

1. Publisher presents the recipient OOB challenge instructions from its application user interface:
   • Select which contact point (mobile phone number or e-mail address) should receive the OOB notification.
   • Press the “Verify Log In” button to trigger the OOB challenge notification.
   • For an SMS text message, respond either via SMS text message or in the application user interface using the ENS-generated OTP verification value presented in the message body.
   • For an e-mail message, respond in the application user interface using the ENS-generated OTP verification value presented in the message body.
2. Publisher sends the <OOBValidateRq> notification request to the Enterprise OOB Service provided by ENS.
3. ENS:
   • Validates the publisher’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.
4. ENS adds a new OOB session for the publisher’s hybrid, two-way use case.
5. Depending on contact ID selected by the recipient to receive the OOB notification, ENS sends the OOB notification as either an SMS message to the recipient’s mobile phone, or as an e-mail to the recipient’s e-mail address.
6. Recipient responds either:
   • Via SMS text message as instructed in the OOB notification using the ENS-generated OTP verification value shown in the SMS message body.
   • Via the application’s user interface as instructed in the OOB notification using the ENS-generated OTP verification value shown in either the SMS or e-mail message body.
7. If the recipient responds with the verification value:
   • Via SMS text message, then ENS verifies the recipient response using the OOB session registered for the recipient’s mobile number and containing the ENS-generated OTP verification value. ENS sends a “90040 – ENS Publisher Feedback” enterprise event confirming that the recipient successfully verified the OOB challenge.
   • In the publisher’s application user interface, then the publisher verifies recipient’s OOB challenge entry and confirms successful user OOB verification.
8. Publisher confirms successful OOB verification to recipient user.

Flowchart

Example Messages

OOBValidate Request

This request sample below:

• Assumes the publisher’s SMS and e-mail message bodies for its “Unknown User OOB Alert” notification already contains the <%$otp%> system constant to:
  • Signal ENS to generate a random OTP in 6-digit numeric format.
  • Substitute the OTP into the message body in replacement of the <%$otp%> system constant.
  • Return the OTP value to the publisher so that it may verify its user from its application user interface.
• Specifies the default, “TwoWay” canonical in the <OOBModeType> value for illustrative purposes. For a hybrid use case—particularly when the recipient may receive the OOB challenge via SMS text message—the publisher should specify a “TwoWay” use case to ensure ENS adds an OOB session to verify, if necessary.
• Includes five additional message body substitution parameters, including an ENS “SmartDateTime”, smart format substitution tag to display the expiration date and time of the OOB challenge in a user-friendly format.
• Alert Request Handlers will ignore substitution parameter, key value pairs that are not used in a particular message body configuration for the notification. In this example, the “salutation” and “timeofday” substitution parameters are used in the e-mail message body, but not in the SMS-native message body.
• Specifies an OOB session duration of 1 hour for ENS two-way verification, if needed.

<SOAP-ENV:Body>
    <OOBValidateRq xmlns=“http://jackhenry.com/jxchange/TPG/2008”>
        <MsgRqHdr>
            <jXchangeHdr>
                <AuditUsrId>AuditUsrId1</AuditUsrId>
                <AuditWsId>AuditWsId1</AuditWsId>
            </jXchangeHdr>
        </MsgRqHdr>
        <AlrtName>Unknown User OOB Alert</AlrtName>
        <OOBRecipInfoRec>
            <ConsmRecipId>MERCHANT89785</ConsmRecipId>
            <OOBRecipInfoArray>
                <OOBRecipConIdInfoRec>
                    <RecipConId>Mobile number</RecipConId>
                </OOBRecipConIdInfoRec>
            </OOBRecipInfoArray>
        </OOBRecipInfoRec>
        <AlrtDataInfoArray>
            <AlrtDataInfoRec>
                <Name>salutation</Name>
                <Val>Mr. Solo</Val>
                <Name>timeofday</Name>
                <Val>morning</Val>
                <Name>username</Name>
                <Val>Corellia</Val>
                <Name>OTPDuration</Name>
                <Val>1 hour</Val>
                <Name>OTPExpires</Name>
                <Val>2017-01-26T14:58:20Z</Val>
            </AlrtDataInfoRec>
        </AlrtDataInfoArray>
        <OOBExpSec>3600</OOBExpSec>
    </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>72e67057-a1d8-4d29-b5fe-95b2d5b1d39f</AlrtPkgId>
        <OTP>561126</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.