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:
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).
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.
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/ |
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/ |
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/ |
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/ |
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 |
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.
Figure 6.1: Frictionless Flow with Attribute Verification Extension
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).
Figure 6.2: Attribute Verification Challenge Approval Flow
This section shows some use cases of the Attribute Verification message extension.
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.
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
|
|
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
|
|
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
|
|
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
|
|
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
|
|
Attribute Verification Request Data | Attribute Verification Response Data |
---|---|
Verification Request Object 1
Verification Request Object 2
| Verification Response Object 1
Verification Response Object 2
|
Last Updated: April 17, 2020
Welcome to EMVCo. By accessing or using the EMVCo website at www.emvco.com (“Site“) or any Site Materials, whether or not you obtained them via the Site, you agree to the following Terms of Use on behalf of yourself individually and the company or organization for which you are using the Site or Site Materials (“Organization“). If you do not agree to the following Terms of Use, do not use the Site or other Site Materials.
In these Terms of Use, “Site Materials” means all email messages sent to you by EMVCo in connection with your registration on the Site or participation in an EMVCo participation program, and all content, files and other materials that are available for viewing or download on the Site, including the EMV® Specifications, requirements, guidelines, white papers or other documents, APIs, SDKs, software, scripts, code, trademarks, videos, text, graphics, pictures, information, and other materials.
You represent that either (a) you are an authorized representative of your Organization with authority to bind your Organization to these Terms of Use, in which case the term “you” refers collectively to both you individually and your Organization, or (b) you are not authorized to bind any Organization to these Terms of Use and are using the Site or Site Materials solely in your personal capacity, in which case the term “you” refers to you individually. EMVCo, LLC (“EMVCo“) reserves the right to modify or replace these Terms of Use at any time and in EMVCo’s sole discretion.
EMVCo will indicate at the top of these Terms of Use the date such document was last updated. Any changes will be effective immediately upon posting the revised version on the Site (or such later effective date as may be indicated at the top of the revised Terms of Use). Your continued use of the Site or Site Materials following the posting of any changes to these Terms of Use will constitute your acceptance of such changes. If you do not agree to the changes, you must stop using the Site and Site Materials. In addition, EMVCo may provide other methods by which you may accept or receive notice of these Terms of Use or changes to these Terms of Use.
In these Terms of Use, “EMV Products” means products or services that are designed to comply with the EMV Specifications. The foregoing license applies retroactively to include activities prior to the date you agreed to these Terms of Use, but is granted solely under the intellectual property rights that EMVCo owns or has the right to license. To the extent the foregoing license includes rights to a third party’s patents, the license is limited to those patents or patent claims that would be necessarily infringed by an entity implementing the mandatory or optional requirements of the EMV Specifications.
And after the cover page of each copy of a translation, the following (or a substantially similar notice) must be printed:
Notwithstanding the foregoing, the Public Documents may be subject to a separate agreement you may have with EMVCo or to supplemental terms and conditions that are included in or accompany Public Documents, in which case you agree that such separate agreement or supplemental terms and conditions will apply to your use of the Public Documents. Any use of the Site or Site Materials other than as specifically authorized herein (or in such separate agreement or supplemental terms and conditions) is strictly prohibited and will automatically terminate the foregoing license without notice.
EMVCo's new website and Participant Dashboard are now live. To access your account for the first time on our new website you'll need to carry out a password reset here. You will then be sent an email to reset your password.
EMVCo Associates, Subscribers and public users of emvco.com can create accounts to manage their engagement and participation with EMVCo. Using your EMVCo account, you can create your own watchlist of EMV technologies documents, monitor queries and responses, and manage your profile.