EMV DPC Credential Specification - Schema Framework - v1.0 DRAFT (Associate Review 1) Disposition of Comments

Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 EA EA Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 GE GE Comment (justification for change) Proposed change The new EMV DPC Schema Framework introduces many new concepts, actors/roles, and functionalities/processes and relies on principles defined in external standards/specifications. The current specification does not contain any definition and/or references sections. As a global comment: DPC topic has never been presented to the associates. In November EMVCo announced the publication of a white paper. We received directly detailed specifications with the description of Data element... Please add both a ‘Definition’ section and a ‘Reference Documents’ section at the beginning of the specification. This would significantly help the understand (and therefore the review) of the proposed specification. It is very difficult to comment on the document. Maybe the organisation of an adhoc SIM will help to understand this notion and how it is included in the Payment ecosystem. As a general comment, EMVCo should take a more explanatory approach as it did for SRC. Status (Accept, Reject, In progress) Accept Accept EMVCo Use Only EMVCo observations on each comment submitted References and Definitions sections have been added on the document, pages iii, iv DIPTF held a dedicated business discussion on 17 March, and a dedicated technical discussion in Singapore Technical meeting on 15 April to further clarify Digital Payment Credential schema. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 1 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section 4 GE General comment: This specification seems to only cover the use case of SCA, not payment initiation. I.e. the DPC is not meant to convey a card (PAN, Token, srcDigitalCardID) to a merchant. Is this assumption correct? GE An illustration (figure) of the DCP ecosystem is missing To add a figure illustrating the DCP ecosystem Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Accept Correct. The current version of DPC only covers a card authentication use case. DIPTF is investigating ways to evolve the DPC to enable payment initiation. Chapter 4 of the document now describes the ecosystem and the roles as a 4-corner model. Furthermore, the roles have been defined in more detail than in the previous version. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 2 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 4 GE It’s unclear how the DPC is managed and Please clarify to what exactly “DPC what “DPC presentation” refers to. presentation” refers to Accept · If the DPC (a list of Data Elements from 5.2 and 5.3) is signed by the Credential Issuer but some of these Data Elements cannot be sent to the credential verifier (for privacy reasons) the “complete” DPC cannot be transmitted. Only the authorized data elements can A clause detailing the DPC processing could be useful. The data elements in a DPC presentation, and displayable ("display metadata") are now defined in more detail in Annex A o Seems therefore that the DPC “presentation” is not to merely transmit the stored DPC (rather some data elements of the DPC) · Is the “DPC presentation” the transmission of the data elements of the “payment sheet” + signature of the payment sheet authenticating such data elements? 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 3 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Section 5.2 Paragraph Ed 3 3rd paragraph: is “using” needed here? Drop “using” Accept Removed EA Section 5.4 ED Introduction of section 5.4 announces that Systematically replace ‘Credential Query’ by Accept Credential selection criteria this section defines 2 types of data ‘Credential Selection Criteria’ (as it seems terminology has been clarified in elements which may be sent in the more explicit) in section 5.4. the document. Payment Request = ‘Payment Details’ + ‘Credential Selection Criteria’. + Rename first column of Table 5.4 as ‘Data More details about the credential Element’ (for homogeneity with other tables) query can be found in Annex A, Section 5.4.2 is titled ‘Credential Query’, ; and suppress ‘Query by’ before each data chapter A.4.2 Sample DCQL introduce the ‘Credential Query data element in this column. Queries elements’ and contains a table 5.4 listing some ‘Credential Queries’. + Clarify column Query Type (e.g. maybe it could indicate “List of values supported”, with a simple explicative sentence in introduction). 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 4 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section Scope GE It would make a lot of sense to provide a We propose the following definition: Accept Additional clarifications added. 2.2. clear definition of the DPC in introduction Usage, roles are defined in Chapter of the document. A Digital Payment Credential is a 4. cryptographically verifiable digital representation of a payment card and related attributes, properly issued by a Credential Issuer, allocated to a legitimate user, and securely stored and properly displayed by a dedicated application referred to as Digital Wallet. A Credential Verifier (usually a Merchant or PSP) can request the Digital Wallet to display a payment sheet, and offer the user the option to choose a DPC representing a Card (possibly with selection criterias received from the Credential Verifier), which is then used to sign the payment sheet details (proof of "sign what you see") and to validate that the Cardholder has been authenticated with MFA. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 5 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 4 GE Section 4 indicates: “The Digital Wallet is We propose adding the following Acknowle Chapter 4 has been re-written to expected to […] Generate a key pair in clarifications: dged clarify the usage, different roles, which the private key is stored securely on and the transaction flow through the the user's device and does not leave the “Credential Issuer acts as the Relying Party four-corner model. device” from the Digital Wallet perspective where the keys are always managed by the wallet, As this document specifies the DPC It would be very useful to precise the under a challenge/response mechanism. In schema, the details of MFA are different technical means to be considered other words, the Relying Party is considered implementation-specific. to achieve MFA (e.g. 2FA based on the systematically involved (both for registration Any rules to how the MFA is to be current definition based on 3 and authentication purpose) in the achieved is expected to come from authentication factor types). cryptographical mechanism.” regulation, credential issuers, credential verifiers, payment Consequently, there is a need to clarify networks, and such. the involvement of the Credential Issuer in the key provisioning. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 6 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 4 GE In this chapter, wording gives the The second paragraph shall indicate that the Acknowle Chapter 4 has been re-written and impression that the Credential Issuer DPC is generated upon the Digital Wallet dged the roles are clarified. Cardholder decides when to generate and provision user’s request. needs to initiate the request / DPCs to the Digital Wallet. provisioning step. It generally works the other way around i.e. the Digital Wallet requests the DPC to be provisioned to the Credential Issuer. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 7 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 5 Table 5.1 GE/TE To ensure compliance with the Co-badged Please apply the following updates: Acknowle Card ID is now specified in and 5.4 Cards management principles already * Keep all the 'Card Co-badged' data dged Chapter 5 at a high level and in applied for other EMV digital technologies elements in table 5.1 as optional data. more detail in Annex A. (such as Tokenisation, SRC,…), and to * In table 5.1: Define the Card PAR inclusion improve flexibility, interoperability, and as Conditional + 'Required in the case of a The handling of co-badged cards in compliance with the different LCM / Co-badged Card (must be systematically the DPC model has not been security rules/ of each underlying payment included by the card issuer or by the changed in this revision. The networks (e.g. transactions could be payment network in this case)’. current specification intentionally processed using a specific key pair for * In table 5.4: For the Queries by Card PAR allows a co-badged card to be each different network), it should also be or by Card BIN + Last 4, clarify that if more represented either as: possible to represent a Co-Badged Card than one credential matches the Query, - a single DPC containing multiple with 2 distinct DPCs corresponding to the digital wallet shall display them as a single supported networks, or 2 schemes/networks (same model as the co-badged card and allow for network - multiple DPCs issued for the same 2 underlying Digital Cards of a Co-badged selection. underlying card, depending on Card, each one managed by the TSP or * In table 5.4: For the Query by Credential issuer and network implementation SRC System of a given network). ID, by Card ID, or by Network Code, clarify choices. how the payment network selection is operated in case of a Co-badged card when Defining normative rules related to: represented by 2 DPCs and when - mandatory inclusion of represented by a single common DPC. co-badge-specific identifiers (such as Card PAR), 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 8 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted - wallet behaviour for aggregating or splitting DPCs, or - deterministic network-selection logic in query handling, would introduce implementation and scheme-specific constraints that are considered out of scope for the current schema-focused version of the specification. EMVCo DIPTF may revisit co-badged card representation, including single- vs multi-DPC models and associated wallet behaviour, in future revisions of the DPC specification or in complementary rulebooks, in alignment with broader EMV digital technologies and scheme requirements. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 9 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 5 GE/TE As requested in previous comment, it shall also be possible to represent a CoBadged Card with 2 distinct DPCs corresponding to the 2 underlying schemes (to ensure compliance with other EMV Technologies). And we recommend defining rules to ensure that a Co-Badged Card represented by 2 distinct DPCs is correctly displayed as a single card visual in the Digital Wallet. These rules should be based on (or directly refer) the rules already defined within the existing EMV digital frameworks such as the EMV Payment Tokenisation (e.g. latest PAR updates) and EMV SRC/CTP (and particularly in the EMV Click to Pay CX Guideline v1.2 – CX Moment ‘Displaying Linked Cards’ = element 4 ‘Co-badged Card’). We strongly recommend adding some rules to request the Digital Wallet to: *identify the Co-badged DPCs (based on the PAR or BIN + Last 4) ; *combine the information/data elements from the 2 DPCs representing a Co-badged Card to display a single Card to the user (using the same principles as already defined in EMV SRC/CTP, with use of the Card art, name, etc… from the DPC corresponding to the currently selected network). *allow for network selection by the Cardholder on the Co-badged Card (using a roll-down menu or radio buttons/logos). Acknowle dged The EMV DPC Schema allows the payment network to be used as a query parameter (for example, to limit credential selection to a specific network). However, the specification does not define normative rules for aggregating multiple DPCs representing a co-badged card into a single wallet visual, nor for cardholder network-selection user-interface behaviour. BIN and PAR are not specified in this version, and co-badged card handling has not been changed in this revision. EMVCo DIPTF may revisit co-badged card representation and associated wallet behaviour in future revisions or complementary rulebooks. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 10 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 5 Table 5.1 TE/MAJ The DPC Schema defines 3 main Please add a clear definition of the Card ID Acknowle Card ID is now specified in OR identifiers which may be used to identify or identifier. dged Chapter 5 at a high level and in to select/filter the DPCs = Particularly, the DPC Schema specification more detail in Annex A. In the DPC * Credential ID = UUID uniquely identifying must clarify if the Card ID represents an model, Card ID represents an a given DPC underlying physical card (e.g. a unique Card opaque identifier for the digitized * PAR = identifier which permits to identify ID represents a Co-badged card with a payment card instance, not the and link the operations performed with a FPAN) or a Digital Card (e.g. it may contain underlying physical card or FPAN, FPAN and its underlying tokens/DPAN, the value of a Token Ref ID, and does not expose PAN, token, and particularly the 2 digital cards srcDigitalCardID, or even a or DPAN values. associated with a co-badged card Token/DPAN…and in this case there are 2 * Card ID = not currently defined (there is distinct Card IDs for a given Co-badged Co-badged card use cases have a sentence in the introduction of section Card). not been changed in this revision, 5.3 - while the data element is listed in And, if EMVCo confirms that it may and no additional co-badge-specific section 5.2 - but it does not permit to represent a Digital Card, then it seems that a identifiers are introduced. EMVCo understand what the Card ID represents) ; ‘Card Co-badged ID’ should be added to DIPTF may revisit co-badged card even if it seems that it is the identifier of a table 5.1, to maintain the option of handling and related identifiers in Digital Card as the DPC Schema applies representing a Co-badged card within a future revisions of the DPC to Remote Payments. single DPC (see previous comments). specification. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 11 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 5 GE Co-badged cards seem to have one DCP Please highlight this matter because it Acknowle The current DPC Schema does not triggers an underlying question about the dged mandate a single representation Credential Issuer model for co-badged cards. A co-badged card may be represented either as: - a single DPC that declares support for multiple payment networks, or - multiple DPCs issued for the same underlying card, each associated with a specific network, depending on issuer and network implementation choices. The handling of co-badged cards has not been changed in this revision. The specification intentionally remains neutral with regard to whether one or multiple DPCs are issued for a co-badged 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 12 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section 5 GE “The credential issuer and wallet will Please clarify enable exchange of information where the credential issuer can request display of specific data elements relevant to the use case and the Wallet can enable that subject to Wallet policies and configurations”. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged card and therefore does not prescribe Credential Issuer responsibilities or wallet behaviour in this area. This flexibility is aligned with existing EMV digital technologies and allows different lifecycle, security, and network-specific rules to be applied as needed. The current version clarifies that issuer requests for display are non-binding and subject to wallet policies and configuration; the DPC Schema does not define or mandate wallet display behaviour. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 13 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 5 Table 5.1 GE Table 5.1: Different Date Elements have a Please clarify justification “ Can be used by the merchant/PSP on the order confirmation page” Is the “order confirmation page” the “payment sheet” presented by the Wallet? Acknowle dged No. In this context, the “order confirmation page” does not refer to the Wallet payment sheet. It refers to the merchant or PSP confirmation page (for example a “Thank you” or order summary page) displayed after the payment has been completed. Earlier drafts of the specification included certain presentation data (such as card art and last-four digits) being returned to the requestor, enabling merchants to display this information on their own post-payment confirmation pages. These elements have since been removed from the presentation data, and the Wallet payment sheet is now clearly separated from any merchant-side confirmation pages. Accordingly, references to “order 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 14 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section 5 Table 5.1 GE 5.1 Attributes “Queried” refers to “matching DPCs” Please clarify What does “filter the matching DPCs” refer to”? Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged confirmation page” should be understood as merchant/PSP UI, not the Wallet-controlled payment sheet. Chapter 5 has been re-written and the more detailed data element descriptions have been moved to Annex A 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 15 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section Table 5.1 TE Different models of co-badging exists but In the row related to “Card Co-badged 5.1 each payment network has its own Network Name”, we propose to replace: implementation roadmap and security rules. Moreover, co-badging can be Inclusion=Conditional handled differently in case it applies to a FPAN or to an EMV Token (DPAN). Each Condition= Required when Co-badged card scheme can also have non co- Network Code Specified badged cards. So for a cobadged card, there is no reason why one By: Scheme/Payment Network would implement DPC just because the other Inclusion=Optional one does (e.g. different approaches related to use cases). Because of the Condition = EMPTY. current uncertainties related to Digital Wallet implementation aspects, there is a need to remain as flexible as possible in the technical arena to properly take into account any lifecycle event related to co- badging. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Co-badge data element details can be found in the added Annex A, chapter A.5 DPC Display Metadata Co-badge use cases have not been changed in this revision. EMVCo DIPTF may revisit the co-badged cards in DPC in later revisions of this document. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 16 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section Table 5.1 TE In Section 5.2 (table 5.1), the DPC We request to rename the fields linked to a Acknowle Co-badge data elements are 5.2 Schema specification introduces specific given network/digital card in table 5.1 (= dged specified in Annex A, chapter A.5 data elements which permit to represent a ‘Card xxx’ and ‘Card Co-badged xxx’ fields) as part of display metadata. Co-badged Card in a single DPC. so that the 2 underlying networks/digital cards corresponding to a Co-badged Card Co-badge use cases have not been Even if do not recommend representing a are presented at the same hierarchical level. changed in this revision. EMVCo Co-badged Card in a single DPC (as it DIPTF may revisit the co-badged does not seem compliant with the digital cards in DPC in later revisions of representation of Co-badged Cards in this document. other EMV Technogies), we want to indicate that if this option is maintained then the field should be renamed so that the 2 underlying networks/digital cards corresponding to a Co-badged Card are presented at the same hierarchical level. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 17 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section Table 5.1 ED In table 5.1, the definition of the Card Co- It shall be replaced by “If not provided, Acknowle Co-badge data elements are 5.2 badged Network Logo URL data element Wallet should display default logo basing on dged specified in Annex A, chapter A.5 indicates: “If not provided, Wallet should the Card Co-badged Network Code”. as part of display metadata. display default logo basing on the Card Network Code”. (+ see comment requesting to ensure that Co-badge use cases have not been the 2 underlying networks of a Co-badged changed in this revision. EMVCo Card are presented at the same hierarchical DIPTF may revisit the co-badged level) cards in DPC in later revisions of this document. EA Section Table 5.1 ED In table 5.1, the definition of the Card Co- The definition of the Card Network Code and Acknowle Co-badge data elements are 5.2 badged Network Code data element Card Co-badged Network Code data dged specified in Annex A, chapter A.5 indicates: ‘Display Meta-Data = Yes’ while elements must be set to the same value as part of display metadata. the Card Network Code data element is (consistency). defined with ‘Display Meta-Data = No’. Co-badge use cases have not been (+ see comment requesting to ensure that changed in this revision. EMVCo the 2 underlying networks of a Co-badged DIPTF may revisit the co-badged Card are presented at the same hierarchical cards in DPC in later revisions of level) this document. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 18 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section Table 5.1 GE Both “Card ID” and “Card PAR” are Make them ‘conditional’? 5.2 optional, but one of the two should be required, shouldn’t it? Acknowle dged Chapter 5 has been re-written and the more detailed data element descriptions have been moved to Annex A EA Section 5.3 ED Section 5.3 indicates: “ the definition of the The definition of the Card Co-badged Acknowle Co-badge data elements are Card Co-badged Network Code data Network Code data element must be dged specified in Annex A, chapter A.5 element indicates: ‘Display Meta-Data = corrected to indicate: ‘Display Meta-Data = as part of display metadata. Yes’ ; which is not consistent with the No’. definition of the Card Network Code data Co-badge use cases have not been element. (+ see comment requesting to ensure that changed in this revision. EMVCo the 2 underlying networks of a Co-badged DIPTF may revisit the co-badged Card are presented at the same hierarchical cards in DPC in later revisions of level) this document. 0 0 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 19 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section Table 5.4 TE Considering there are different ways to In the Wallet Remarks column of table 5.4, 5.4 consider co-badging, and that section 5.2 even when one single DPC credential is seems to propose the option to represent retrieved/selected, there is a need to a Co-badged Card a single DPC = a DPC consider that the Wallet provides the can be allocated with 2 Payment opportunity to consider Payment Networks. network/DPC selection. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Requestor may request a DPC per network, including those defined for the co-badged network. Co-badge use cases have not been changed in this revision. EMVCo DIPTF may revisit the co-badged cards in DPC in later revisions of this document. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 20 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Section 5.4.1 Table 5.3 TE Payment details schema and external alignment a) Reference to FIDO transaction data Section 5.4.1 defines “payment details.” In parallel, the FIDO PWG is updating its charter to include issuance of transaction data. It would be helpful to clarify how this development impacts the DPC schema. If future versions rely on a FIDO-issued transaction data schema, there is a risk of fragmentation and increased implementation complexity for wallet providers maintaining compatibility with multiple data definitions. We recommend clarifying this point before publication. b) Alignment with European SCA the following items could be considered: Acknowle dged · Inclusion of a Payment Reference equivalent (mandatory in TS 12). · Addition of a PISP Facilitation Indicator. · Inclusion of Payment Execution Date. · Support for MIT parameters such as minimum/maximum amount limits. · Furthermore, TS 12 already includes transaction data definitions for the NPA (non-payment authentication) case. As EMV 3DS also covers NPA, introducing NPA authentication within DPC would promote 1. Added Payment Reference Possible future amendments and changes to DPC Schema: 2. Take MIT parameters to a later revision. The Payment Context / Transaction Data will be revised later as Fido PWG and other organizations specify this in more detail. 3. NPA is out of scope in DPC, another credential may be used 4. PISP Facilitiaion and Payment Execution Date to a future version when payment initiation is discussed 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 21 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Attestation (TS 12 ARF) The ongoing European TS 12 ARF work on SCA attestation introduces several elements not yet covered in the current DPC schema, despite existing alignment efforts. To support adoption and interoperability, increased alignment would be beneficial. convergence between DPC and 3DS for both PA and NPA scenarios. General comment: This specification seems to only cover the use case of SCA, not payment initiation. I.e. the DPC is not meant to convey a card (PAN, Token, srcDigitalCardID) to a merchant. Is this assumption correct? EA Section Paragraph ED The 4th paragraph mentions the 5.4.1 4 ‘requestor’. Shouldn’t this be the “Credential Verifier’? Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Section 5 has been reformatted and now references 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 22 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA Section Table 5.3 GE EMV 3DS 2.3.1 specifies a ‘variable 5.4.1 frequency’ in the ‘frequency indicator’; shouldn’t this be supported by the DPC as well? Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Recurring transaction data is described only on a high level on table 5.3 This document does not specify the presentation request data schema. That is specified by - Fido Alliance, generic payment context that can be used in DPC context, displayable by wallets - European Commission, EUDI / eIDAS context, "TS12" - potentially other organizations Future versions of this document will have references to payment context / presentation request details and specifications. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 23 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section Table 5.3 GE In EMV 3DS 2.3.1, the “Recurring Shouldn’t the DPC spec follow the EMV 3DS Acknowle Recurring transaction data is 5.4.1 First/Last Payment Date” is ‘conditional’ 2.3.1 definition? dged described only on a high level on not ‘optional’. table 5.3 This document does not specify the presentation request data schema. That is specified by - Fido Alliance, generic payment context that can be used in DPC context, displayable by wallets - European Commission, EUDI / eIDAS context, "TS12" - potentially other organizations Future versions of this document will have references to payment context / presentation request details and specifications. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 24 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA Section Table 5.3 ED Typo ‘cand’ in the “Condition” clause of 5.4.1 “Recurring Number of Payments” Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Recurring transaction data is described only on a high level on table 5.3 This document does not specify the presentation request data schema. That is specified by - Fido Alliance, generic payment context that can be used in DPC context, displayable by wallets - European Commission, EUDI / eIDAS context, "TS12" - potentially other organizations Future versions of this document will have references to payment context / presentation request details and specifications. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 25 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section 6 GE These Security and Privacy considerations To be completed, including in particular seem incomplete provisions for 1. Key management clarifications 2. Digital signature generation and verification mechanisms 3. Authentication mechanisms between parties exchanging sensitive data 4. Protection of sensitive data in transit Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dged Yes, the chapter 6 is very limited for now. Much of the details are defined in other specifications. DIPTF is considering how to modify the chapter as this document scope is limited to the DPC Schema. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 26 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Sections TE 5.1, 5.2 and 5.3 In Section 5.2, it is indicated "The credential issuer should be able to specify to the wallet what data fields can be displayed" ; which seems in contradiction with the fact that section 5.1 defines the attribute ‘Displayed’ as "Digital Wallet shall display the data to the user on the payment sheet” + table 5.1 defines most data elements with the attribute ‘Display Meta-Data’ = Yes (which seems to indicate that it is mandatory to display these data elements). Also, in section 5.3, it is indicated “As described before, the credential issuer should be able to request display of relevant data elements at the time of the transaction”; while all the data element of table 5.2 are defined with the attribute ‘Display Meta-Data’ = No. In section 5.2: Please clarify if it is mandatory to display the data elements indicated as ‘Displayed’, or if the Credential Issuer may request not to display these data elements (and how). In section 5.3: we propose to simply suppress the sentence “As described before, the credential issuer should be able to request display of relevant data elements at the time of the transaction" as it does not apply here (else, we request the same clarifications than on section 5.2). Acknowle dged The parts in the document that describe the displayable data elements, and what can be queried, have been updated. - Chapter 5 defines the data elements in high level - Annex A, chapter A.5 specifies the display metadata that can be included in the DPC 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 27 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 GE This Draft specification focus on the list of Data Elements to be used for (1) an issuer to design its DPC and (2) for a credential verifier (payee) to provide the transaction data for explicit approval by the payer of the payment using a digital signature. This comprehensive list of Data Elements is a condition for the interoperability of DPC. It is also intended to ensure that EMV DPCs are secure, privacy-preserving, and regulatory-compliant. In particular this functionality is useful to comply with PSD2 SCA requirements for online payments. Acknowle dged This version of the DPC covers only the schema for a DPC with a use case of payment authentication. Following versions of the schema may be extend to payment imitation. Latest version extends the schema to a specification-level document with some of the proposed additions. Our understanding is that this Draft supports six basic processes: 1. DPC provisioning, involving a protocol between the Wallet and the Credential Issuer 2. Discovery of the DPC by the Credential Verifier followed by 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 28 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted 3. Payment request by the Credential Verifier, involving a protocol between the Wallet and the Credential Verifier to transport a series of data elements related to the Credential Verifier and transaction payment details 4. Presentation of the payment sheet for signature by the Wallet, involving an interaction between the Payer and the Wallet 5. Generation of the signature by the wallet upon payer consent and transmission of the signature by the Wallet to the Credential Verifier 6. Verification of the wallet signature, requiring a protocol between the Credential Verifier and the Credential Issuer 7. Exchange of information between Credential issuer and Wallet (Ch 5) Yet the specification only provides a high- 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 29 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted level framework for the interface between a Digital Wallet storing the DPC and the broader online card payment system. This version fails to delve into detailed technical implementation or API-level interactions with a specific payment application. This draft appears somehow underspecified according to its title: “Schema Framework”. With that regard may be a title such as “Data Elements for the Interoperability of Digital Payment Credentials” could be more appropriate. That’s consistent with the scope of the Draft as described in section 2.2. For instance, the document does not specify how the wallet communicates with the payment application (e.g., message formats for all the above data exchanges). Moreover the current version does not describe how the wallet integrates with a 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 30 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted specific payment app (e.g., mobile app, web app) or the underlying communication layers. Therefore we assume that the protocol-specific aspects will be laid on i.e., ISO/IEC 18013-5 & 18013-7, W3C VC, SD-JWT. Even if this neutral “underdefinition” approach makes the DPC more prone to integration in different remote commerce ecosystems, some examples of implementation could be useful. We suggest the production of at least two Data Flows for clarification purposes: • One describing the interactions between the Wallet and the Credential Issuer for the issuance and subsequent loading of the DPC into the Wallet • A second one, describing the interactions between the three parties involved in the payment transaction based on DPC presentation 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 31 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted • Clarify the steps included in the “DPC Presentation” With that respect ISO/IEC TS 23220-4 (Protocols and services for operational phase) may be an appropriate reference on building blocks for identity management via mobile devices. While this Draft requires the wallet to display a payment sheet, it does not provide UI guidelines, or a step-by-step user flows. No details are provided in the interaction between the payer and the wallet storing the DPCs, activation of the Wallet for instance. We assume that the implementation if the UI is in the competition domain and that this interaction is left up to EMVCo issuers or that is assumed to be implemented inherently by the Wallet storing and presenting the DPC. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 32 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change For the sake of clarification, it could make sense to add a Terminology as new section 3. The different cryptographic keys involved in the DPC and their nature and ownership should be clarified in section 6. The following comments are not a critical review of the Draft content in terms of the list of Data Elements proposed. We focus on suggestions to move ahead to complete the Framework and to provide clarifications on some of the Draft provisions. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 33 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 1 Executive GE Wallet architectures such as the EUDI Please clarify whether face-to-face channel Reject The document states that this Summary Wallet ARF include the F2F channel as an is explicitly excluded by the EMV DPC specification is for remote option. framework. commerce, and this schema definition is for online use only. The proximity presentation use cases in ARF are not specified in this document. Also, the document (chapter 4) states that regulatory frameworks are not in scope of this document. EA Section 1 Executive GE The last paragraph indicates “…common We propose to clarify as follows: Reject The use cases are discussed in Summary interpretation of data elements when it more detail in chapter 3. This relates to a transaction.” “…common interpretation of data elements document uses term "Multi-Factor when it relates to a transaction or other Authentication" rather than "Strong DPCs maybe be used for other operations (e.g. SCA)”. Customer Authentication" SCA. operations, such as Strong Customer MFA is more generic and not Authentication (as per §3 Use cases), associated with a regulatory hence we would suggest using a more meaning, as SCA is. generic term. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 34 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 3 GE It would be very useful to remind the key Please add a clear definition of what are the Reject Multi-factor authentication is a principles to consider about MFA. different types of authentication factors generic term that typically require considered for an Authentication with ‘MFA’. use of biometrics, device-bound cryptography, and such. SCA has clear definitions from regulation, but as this document is regulation agnostic, the same definitions do not apply. Hence, MFA is used as it is broader. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 35 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 3 Section 3 GE Scope limitation to MFA use case (Section Including payment initiation from version 1 Reject The current version of the DPC for 3) The document currently focuses would streamline the user experience by payment cards enables payment exclusively on the multi-factor reducing friction, simplify merchant/PSP authentication during an online authentication (MFA) use case, without flows, and align with European LSP payment payment transaction. DIPTF will addressing payment initiation. The MFA expectation scenarios. This approach would explore additional use cases for scenario inherently involves user selection also position DPC as a foundational scheme Digital Payment Credentials, of a payment card (e.g., CoF, Guest for card-based payment use cases. including payment initiation, and Checkout, CTP), where the merchant or potentially will expand the PSP would trigger the DPC presentation document scope in the following via the DC API or other mechanisms. versions. While this use case is essential, combining MFA with payment initiation would unlock broader opportunities and accelerate adoption. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 36 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 3 Table 5.1 te Clarification on “cardID” and guest checkout (Table 5.1) Table 5.1 includes the field card ID, described as enabling the merchant to use the card in a guest checkout scenario. Does this imply that the current DPC schema supports guest checkout payment initiation? If so, the current structure appears limited to tokenized cases and may seem inconsistent with the Credential Type field, which currently supports only the value authn. If this is not a payment initiation use case but rather an authentication one, the current definition appears to be limited to a guest checkout service where the tokenized credential is used for authentication via a PAR or cardID Suggestion 1 - Expand the Credential Type to include combined “payment + authentication” scenarios Suggestion 2 - Consider extending the mechanism (beside ‘card id’) to cover a wider range of ecosystems, avoiding potential fragmentation where different card networks might adopt alternative schema definitions. Reject The current version of the DPC for payment cards enables payment authentication during an online payment transaction. DIPTF will explore additional use cases for Digital Payment Credentials, including payment initiation, and potentially will expand the document scope in the following versions. 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 37 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) reference. In both cases, this restriction narrows the scope of applicability and may not fully support the broader variety of integrations and may limit the interoperability. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 38 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Identity and Payments Task Force (DIPTF) Document: EMV Digital Payment Credential Specification - Schema Framework - v1.0 Date: May 2026 DRAFT EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/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 Section 3 GE It’s understood that “Use-Cases” refer to Please complete. Reject The DPC Schema defines the use “DPC Use Cases”. Wallet is assumed to of Digital Payment Credential from implement a strong Multi-Factor For instance a technical aspect. The document is Authentication (MFA) such as biometrics written to be regulation agnostic. or PIN, combined with a device-bound “The second factor for compliance with the key, to produce a signed presentation SCA seems to be the signature of the payload. payment sheet with the payment details by the wallet. The SCA is completed once this Yet the Draft fails to explain how the DPC signature has been verified. Because only is used for Payment SCA according to the Credential Issuer holds the pair public PSD2. key, the Credential Verifier must transmit the signature to the Credential Issuer for Verification” But in that case why we call it “Credential Verifier”,if it cannot verify anything? 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. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 08-May-2026 Page 39 of 46 Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all comments Primary Contact Name: Working Group or Task Force: Digital Id