EMV® 3-D Secure Attribute Verification Message Extension v1.0 - DRAFT - Disposition of Comments

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV® 3-D Secure Attribute Verification Message Extension v1.0 – Draft Date: July 2024 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Table/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA Survey 1.a) Should Verification Method ge We’d consider the ACS ultimately responsible for the N/A response be defined as a string? If so, what length should be defined verification of the attributes in question. Therefore, the resultCode returned should be guaranteed as valid. for the string? Allowing additional “trust level” option in the verificationMethod could complicate the things from a consumer perspective by subtly introducing a “more trusted” and “less trusted” verification sources for a specific attribute. A free string does not add much value in the automated processing rather a log opportunity for audit reasons. We’d rather prefer an enum or a json sub-structure for each of the potential values (DMV, IRS, Govt) stated in the table. EA Survey 1.b) In your view, can ge Yes, it can, either in the same field as part of a defined N/A response Verification Method carry additional information such as a structure(json), or in a separate one (e.g verificationMethodData max 20000 chars) where the digital signature as proof of raw data would be formatted according the verification verification? If so, should it method. This will allow ACS’s to be used as brokers to therefore be defined as a large third party verifiers (age, name, etc.) while the liability of object (20,000 characters)? the verification stays within the third parties. With this, the client (3ds requestor) is responsible for verification Accept Ultimately it is the ACS’s responsibility for the verification. The Verification Method can be used simply for reporting how the verification was completed. It is an optional element, and an ACS may choose not to send this data. We would need more hindsight before defining the data formats. Accept This can be added as a potential enhancement in future versions of the message extension.

rogress) EMVCo Use Only EMVCo observations on each comment submitted of the validity and using the “signature” in case of disputes. EA Survey 1.c) Do you have any other ge To reduce complexity, in this rather early phase, we’d N/A response thoughts or feedback regarding this data element? recommend omitting this element and transfer the responsibility to the ACS for the validity of the resultCode. If the ACS supports attribute verification (e.g. age), we’d expect high quality of the data and full trust in the ACS. EA Survey 2.a) In case of a challenge, response should the message extension be present in the ARes and RReq messages or only in the RReq message? ge Several aspects. N/A 1. Extension usage in PA or NPA 2. Is SCA required? / cardholder consent for attribute verification Simpler use case is if the extension is used in NPA. Then the sole purpose of the 3DS transaction would be the attribute verification (although it can be combined with other NPA use-cases). Here, the ACS may decide to return the information frictionless (ARes), challenge the cardholder (second ARes in SPC or RReq) or ask an explicit consent from the cardholder for each Accept Accept To reduce complexity, Verification Method is made as an optional element, and an ACS may choose not to send this data. The 3DS Server/Merchant shall rely on the Result Code. To add simplicity, a Verification Response Indicator has been added to the message extension to signal to the requestor that all attribute verification result codes will be provided in either the ARes or RReq message. The ACS decides whether a challenge is necessary to respond to the Attribute Verification Request and sets the Verification Response Indicator accordingly.

rogress) EMVCo Use Only EMVCo observations on each comment submitted attribute being asked for and return the results in the RReq based on cardholder’s approval – assuming the challenge pages allow this. In case of PA, the acs already has a primary task – authenticate the payment. The combination with the previous cases where attribute verification is needed would complicate the processing even more. EA Survey 2.b) Should the presence of the ge The presence of the extension should be tied to the N/A response message extension in the ARes and RReq messages be tied to internal ACS logic based on local regulations, cardholder preference and best practices. Me as a Transaction Status in the core cardholder may give a consent to my bank (acs owner) message? to allow attribute verification without SCA – e.g anyone using my cardnumber for the sole purpose of age verification will get immediate response (in ARes). When combined with PA, the acs may return the verification in ARes but do challenge for the PA. On the other side, me as a cardholder may ask my bank to explicitly ask for my consent whenever my personal information (attributes) is queried. Then the ACS would challenge (in edge cases even explicitly ask for specific consent) from me as cardholder for the attribute Accept To add simplicity, a Verification Response Indicator has been added to the message extension to signal to the requestor that all attribute verification result codes will be provided in either the ARes or RReq message. This indicator avoids complex presence conditions with the Transaction Status.

rogress) EMVCo Use Only EMVCo observations on each comment submitted EA Survey 2.c) Do you think an alternative ge response approach would be preferred in this scenario? If so, what would you recommend? verification. In this case the result will be returned in RRes. Unsuccessful authentication (rba/sca) may stop the attribute verification – but not necessary depending on the context that is used. For simplification, this extension could be limited only N/A for NPA transactions, binding the 3ds transaction with the attribute verification process. Additional signal indicating no-challenge or fail in the VerificationRequestData could force frictionless retrieval (in AReq) of the result (matched, not-matched, attribute-available -challenge-needed). If challenge is needed for the specific attribute verification, a follow up NPA may be issued by the 3DS requestor, this time without the “no-challenge of fail” signal, allowing the acs to challenge the transaction to return the verification response after successful challenge (in RReq). Accept The main use cases are related to payments for which the customer’s age must be verified before proceeding with the transaction. To simplify the ACS and 3DS Server processing, a Verification Response Indicator has been added to the message extension to signal to the requestor that all attribute verification result codes will be provided in either the ARes or RReq message. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. © 2024 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.

of 4