Attribute Verification Message Extension

Business Overview

The Attribute Verification Message Extension allows a 3DS Merchant to isolate a specific piece of data about a user and have it verified by a trusted source in the 3DS ecosystem. The purpose of the extension is to satisfy requirements imposed by global regulations mandating that certain types of attributes be individually confirmed to make purchases, set up new subscriptions, access adult content on the internet, or even create new social media accounts. Its intention is to minimise the amount of data necessary to be shared amongst parties in order to satisfy these requirements, while leveraging the existing and widely adopted 3DS infrastructure for ease of implementation.
Examples of verifiable attributes include but are not limited to:

  • Age – for purchasing restricted goods such as alcohol and tobacco or creating a new social media account.
  • Government ID numbers – for placing online bets via gambling platforms.
  • Residency – for purchases where verification of residency is required to set up a recurring subscription.
  • Billing/Shipping addresses – for Merchants that may require additional verification on an address for higher purchase amount transactions.

Benefits by Actor

Merchant
  • ability to comply with Cardholder attribute verification regulations to complete purchases, set up accounts, view internet content, or place online gambling bets
Issuer
  • ability to leverage the account data it already has for its Cardholders in order to perform attribute verification
  • ability to use its existing 3DS rails for attribute verification
Cardholder
  • decreases the amount of data about the Cardholder that needs to be shared to complete the transaction
  • allows the Cardholder to use their familiar 3DS authentication experience to complete attribute verification

 

Technical Features

Overview

The Attribute Verification Message Extension is a non-critical message extension, which means that support for this feature is not mandatory. It is applicable for the Browser, App and 3RI message channels. It also applies to both Payment and Non-Payment message categories. The Verification Request Data is sent as part of the AReq message, and the Verification Response Data is sent as part of the ARes and RReq messages if a challenge is required by the ACS.

The requestor may choose from predefined attributes within the extension itself that do not currently exist in the Core Specification. Examples of these attributes are age, date of birth, citizenship, and ID number. Requestors can also refer to a set of existing data elements within the AReq message for attribute verification. Examples of these are cardholder name, billing address, and home phone number. The Attribute Verification Message Extension allows for multiple attributes to be requested within the same message.

The requestor can select the match type, which is the method needed to be performed against the value being requested to be verified. These are the mathematical operators: greater than; less than; greater than or equal; less than or equal; equal and not equal (match type values 01–06, respectively). The final match type is compare (match type value 07). For an attribute request where the value to be verified is numeric, the requestor selects a mathematical operator to be applied to the request. For non-numeric values, the requestor uses the compare match type.

The validating system should return result codes indicating that the verification matched successfully (or true); not matched (or false); attribute requested is supported for verification but could not complete the request; or attribute requested is not supported for verification (result code values 01, 02, 04, 05, respectively) for match types that are numeric operators. The validating system should return result codes that the verification matched successfully (or true); not matched (or false); matched partially; attribute requested is supported for verification but could not complete the request; or attribute requested is not supported for verification (result code values 01, 02, 03, 04, 05, respectively) for the match type compare.

The validating system has the option to respond with the outcome of the Attribute Verification Request in either the ARes or the RReq, depending on whether challenge processing is necessary for a response. All attribute results must be responded to in the same message. If the verifying system chooses to respond frictionlessly, it will set the Verification Response Indicator = N (All verification responses are only provided before challenge processing) in the ARes message along with the Verification Response Object. If the verifying system chooses to respond after a Cardholder challenge, it will set the Verification Response Indicator = Y in the ARes message only, and it will then send the Verification Response Object in the RReq, which will contain the results of the attributes requested to be verified.

In the case of merchant-initiated SPC, where the validating system requires a challenge to respond to the Attribute Verification Request, the validating system will set the Verification Response Indicator = Y in the first ARes message that sets up the SPC challenge for the Merchant. The requestor will repeat the Verification Request Object in the second AReq message. The validating system will then send the Verification Response Object with the attribute verification outcome in the second ARes message of the merchant-initiated SPC challenge.

If the verifying system suspects that an attribute verification request has been submitted with fraudulent intent, it will respond back with a non-successful Result Code in the Verification Response Object and a non-successful Transaction Status in the core authentication message. It will also set the Transaction Status Reason in the core authentication message = 11 (Suspected fraud).

Preconditions

It is presumed that the message extension is supported by the 3DS Server, the ACS, and the DS.

The Frictionless and Challenge Flow sequence diagrams below show the 3DS Server as the system sending the Attribute Verification Request, and the ACS as the system sending the Attribute Verification Response. However, the extension allows for the DS to be the system performing either the request or the verification. In this case, the flow remains the same, except it is the DS that populates the Verification Request Data in the AReq message or the Verification Response Data in the ARes/RReq messages. If the DS is the verifying system, then the Verification Response Indicator will always be set to N in the ARes (all attributes will be verified in the ARes).

Note: Since the attribute verification may involve private or sensitive cardholder data, and to comply with local regulations, the 3DS Requestor and/or ACS should obtain cardholder consent before proceeding with the verification.

3DS Data Elements Related to the Attribute Verification Extension

The data elements listed in Table 6.6, Table 6.7, Table 6.8 and Table 6.9 below are part of the Attribute Verification Message Extension. For additional information, please refer to the EMV 3-D Secure Attribute Verification Message Extension.

Table 6.6: Attribute Verification Data Elements

Data Element/
Field Name

Description

Version

Assigned Extension Group Identifier

A unique identifier for the extension.

2.3.1

2.2

Criticality Indicator

A Boolean value indicating whether the recipient must understand the contents of the extension to interpret the entire message.

2.3.1

2.2

Data

The data carried in the extension.

2.3.1

2.2

Extension Name

The name of the extension data set as defined by the extension owner.

2.3.1

2.2

Table 6.7: Data

Data Element/
Field Name

Description

Version

Verification Request Data

The data specific to the Verification Request.

2.3.1

2.2

Verification Response Data

The data specific to the Verification Response.

2.3.1

2.2

Verification Response Indicator

Indicates whether the verification response will be provided after challenge processing.

Note: For Merchant-initiated SPC, and if Verification Response Indicator = Y in the initial ARes message, the 3DS Server repeats the verification request in the second AReq message.

2.3.1

2.2

Extension Version Number

Version number of the message extension.

2.3.1

2.2

Table 6.8: Verification Request Data

Data Element/
Field Name

Description

Version

Attribute Name

Indicates the type of attribute verification requested.

2.3.1

2.2

Match Type

Indicates the verification method needed.

2.3.1

2.2

Match Value

Indicates the value against which the verification will be performed

2.3.1

2.2

Core Attribute Field

Indicates the field name present in the core message against which the verification will be performed.

2.3.1

2.2

Table 6.9: Verification Response Data

Data Element/
Field Name

Description

Version

Attribute Name

Indicates the type of attribute verification requested.

2.3.1

2.2

Core Attribute Field

Indicates the field name present in the core message against which the verification was performed.

2.3.1

2.2

Verification Response Source

This data element will be populated by the system setting Verification Response.

2.3.1

2.2

Result Code

Status of the verification request.

2.3.1

2.2

Reason Code

Provides information on why the Result Code field has the specified value.

2.3.1

2.2

Verification Method

Provides information on what method was used by the source for the attribute verification.

2.3.1

2.2

Attribute Verification Frictionless Approval Flow (App-Based, Browser-Based or 3RI Channel)

Overview

In the attribute verification frictionless approval flow, the 3DS Server provides the relevant transaction data and Attribute Verification Request Data in the AReq. The ACS determines that the information provided is sufficient to make a decision on the Attribute Verification Request and sends the applicable Result Code back to the requestor in the Verification Response Data in the ARes. The ACS will also set the Verification Response Indicator = N, signalling to the requesting system that all attributes will be verified in the ARes.

Note: The decision on the Attribute Verification Request is independent of whether the authentication decision is completed frictionlessly or via a challenge. The ACS can send the Attribute Verification Response decision in the ARes, but the authentication is still challenged by the ACS.

Sequence Diagram

  1. The Cardholder makes a purchase or authentication request that requires an attribute verification.
  2. The 3DS Requestor initiates a 3DS authentication and provides details about the purchase or non-payment request, along with the attribute to be verified.
  3. The 3DS Server sends an AReq message including the Attribute Verification Message Extension populated with the Verification Request Data, specifying the attribute(s) to be verified and the type of verification method to be applied to the attribute(s).
    a. If the attribute is a data element that does not exist in the Core Specification (i.e., Attribute name = 01/Age, 02/Date of Birth, 03/Citizenship, 04/ID Number), then the Match Value is populated for the attribute.
    b. If the attribute is a data element that does exist in the Core Specification (i.e., Attribute name = 05/Core Attribute), then the Core Attribute Field is populated indicating the field name present in the core message that the validating system will need to use to perform the verification.
  4. As part of its standard risk assessment, the ACS verifies the attribute(s) being requested and responds setting the Verification Response Indicator = N and the Verification Response Data including the result of the attribute verification in the ARes message (Result Code = 01/Matched successfully or true, 02/Not matched or false, 03/Matched partially, 04/Attribute is supported but could not be verified, or 05/Attribute requested is not supported for verification)

 

Figure 6.1: Frictionless Flow with Attribute Verification Extension

Attribute Verification Challenge Approval Flow (App-Based, Browser-Based or 3RI Channel)

Overview

For the attribute verification challenge approval flow, the 3DS Server provides the relevant transaction data and Attribute Verification Request Data in the AReq message. The ACS determines that the Cardholder needs to complete a challenge before confirming the Attribute Verification Request. The ACS returns a response to the requestor in the ARes message that the outcome of the Attribute Verification Request will be provided in the Results Request (RReq) message by setting the Verification Response Indicator = Y. The Cardholder is challenged, and the ACS provides the Verification Response Data object(s) containing the attribute Result Code(s) to the requestor in the RReq message.

Note: If the ACS determines that the Attribute Verification Request must be challenged in order to respond with a decision, then the AReq also goes through the Challenge Flow (Transaction Status = C/D/S in the ARes message).

Sequence Diagram

  1. The Cardholder makes a purchase or an Authentication Request that requires an attribute verification.
  2. The 3DS Requestor initiates a 3DS authentication and provides details about the purchase or non-payment request, along with the attribute to be verified.
  3. The 3DS Server sends an AReq message including the Attribute Verification Message Extension populated with the Verification Request Data specifying the attribute(s) to be verified and the type of verification method to be applied to the attribute(s).
    a. If the attribute is a data element that does not exist in the Core Specification (i.e., Attribute name = 01/Age, 02/Date of Birth, 03/Citizenship, 04/ID Number), then the Match Value is populated for the attribute.
    b. If the attribute is a data element that does exist in the Core Specification (Attribute name = 05/Core Attribute), then the Core Attribute Field is populated indicating the field name present in the core message that the validating system will use to perform the verification.
  4. As part of its standard risk assessment of the AReq, the ACS determines that the attribute(s) being requested require(s) a challenge to be performed to provide a result of the attribute verification. The ACS sends the ARes message with Transaction Status = C/D/S along with the Verification Response Indicator set to Y (all verification responses are provided after challenge processing).
  5. The 3DS Requestor Environment and the ACS proceed with the challenge.
  6. The Cardholder completes the challenge.
  7. The ACS provides the outcome of the authentication in the RReq message and includes the Result Code(s) for the attribute verification in the Attribute Verification Response data (Result Code = 01/Matched successfully (or true), 02/Not matched (or false), 03/Matched partially, 04/Attribute is supported but could not be verified, or 05/Attribute requested is not supported for verification).

Figure 6.2: Attribute Verification Challenge Approval Flow

Use Cases

This section shows some use cases  of the Attribute Verification message extension.

Preconditions

The verifying system successfully confirmed the attribute(s) requested.
The verifying party is the ACS.

 

Use Case 1: Age Verification (verifying that the Cardholder is at least 18 years old)

Use Case 2: Date of Birth Verification (verifying that the Cardholder was born on 13 December 1989)

Use Case 3: Citizenship Verification (verifying that the Cardholder is a citizen of the United States)

Use Case 4: ID Number Verification (verifying a government-issued ID number of the Cardholder)

Use Case 5: Cardholder Name Verification (verifying that the submitted name matches what is on file for the Cardholder)

Use Case 6: Multiple Attributes Requested in a Single Message (verifying a Cardholder’s age and name in the same Attribute Verification Request)

The tables specify the data required for each use case.

Age Verification – verifying that the Cardholder is at least 18 years old

Attribute Verification Request DataAttribute Verification Response Data
  • Attribute Name = 01 (Age)
  • Match Type = 04 (Greater than or equal)
  • Match Value = 18 (Minimum age of user to be confirmed)
  • Attribute Name = 01 (Age)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

Date of Birth Verification – verifying that the Cardholder was born on 13 December 1989

Attribute Verification Request Data

Attribute Verification Response Data

  • Attribute Name = 02 (Date of Birth)
  • Match Type = 05 (Equal)
  • Match Value = 19891213 (Date of birth of cardholder to be confirmed in YYYYMMDD format)
  • Attribute Name = 02 (Date of Birth)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

Citizenship Verification- verifying that the Cardholder is a citizen of the United States

Attribute Verification Request Data

Attribute Verification Response Data

  • Attribute Name = 03 (Citizenship)
  • Match Type = 05 (Equal)
  • Match Value = 840 (ISO 3166-1 numeric country code for USA)
  • Attribute Name = 03 (Citizenship)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

ID Number Verification – verifying a government-issued ID number of the Cardholder

Attribute Verification Request DataAttribute Verification Response Data
  • Attribute Name = 04 (ID number)
  • Match Type = 05 (Equal)
  • Match Value = 1111222233334444 (example value of ID number to be verified)
  • Attribute Name = 02 (ID number)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

Cardholder Name Verification – verifying that the submitted name matches what is on file for the Cardholder

Attribute Verification Request DataAttribute Verification Response Data
  • Attribute Name = 05 (Core attribute)
  • Match Type = 07 (Compare)
  • Core Attribute Field = cardholderName (Field in the Authentication Request message the verifying system will use to perform the verification)
  • Attribute Name = 05 (Core attribute)
  • Core Attribute Field = cardholderName (Field in the Authentication Request message the verifying system will use to perform the verification)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

Multiple Attributes Requested in a Single Message – verifying a Cardholder’s age and name in the same Attribute Verification Request

Attribute Verification Request DataAttribute Verification Response Data

Verification Request Object 1

  • Attribute Name = 01 (Age)
  • Match Type = 04 (Greater than or equal)
  • Match Value = 18 (Minimum age of user to be confirmed)

Verification Request Object 2

  • Attribute Name = 05 (Core attribute)
  • Match Type = 07 (Compare)
  • Core Attribute Field = cardholderName (Field in the Authentication Request message the verifying system will use to perform the verification)

Verification Response Object 1

  • Attribute Name = 01 (Age)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))
  • Reason Code = 01 (Data available and verified successfully)

Verification Response Object 2

  • Attribute Name = 05 (Core attribute)
  • Core Attribute Field = cardholderName (Field in the Authentication Request message the verifying system will use to perform the verification)
  • Verification Response Source = 01 (ACS)
  • Result Code = 01 (Matched successfully (or true))