EAASD-JWT VCmdoc

Attestation Rulebook for attestations of type SCA Card DPC

Category: non-qualified EAA

[Based on the WE BUILD attestation description: https://portal.webuildconsortium.eu/group/wp3-technology-standards/files?mid=7109&fid%5B0%5D=6880&fid%5B1%5D=7094]

[The data model of this attestation is derived from the EMVCo specification "EMV Digital Payment Credential (DPC) - Card Credential & Display Meta-Data"]

• Author(s):
  • Tomasz Błachowicz, Mastercard

Feedback:

• Github, portal, email, Slack

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues

1 Introduction

1.1 Document scope and purpose

SCA-Card (DPC) specifies the card-level SUA attestation described in [TS12] published by the European Commission. The attestation represents a digitised payment card as a verifiable credential, called a Digital Payment Credential (DPC), and is used for payment authentication with multi-factor authentication in remote commerce. It supports both authentication of a card already known to the merchant (for example a token on file or a recognised returning consumer) and credential discovery with card selection in the Wallet, which enables the authenticated guest checkout scenario.

The attestation follows the data minimisation principle: the signed payload identifies the payment instrument through opaque identifiers only and never contains the PAN or fragments of it. All presentation-oriented card data, such as the last four digits, card art, and branding, travels in a separate unsigned display meta-data object defined in this document.

In this document we specify attributes, allowed formats, and processing rules for this attestation. The data model is derived from the EMVCo Digital Payment Credential specification [EMV-DPC] and adapted to the WE BUILD SCA attestation family. Co-badged cards, which [EMV-DPC] supports through a per-badge credential model, are out of scope for WE BUILD; see Section 2.1.

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], to indicate requirements, recommendations and options.

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF.

Please note that terms credential and attestation are interchangeable for the purpose of this document.

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

This Rulebook is aligned with the following specifications:

• [European Digital Identity Regulation] (Regulation (EU) 2024/1183) - This is a non-qualified EAA. Attributes and metadata satisfy the requirements of Annex V points b), c), and e) as applicable (ARB_15, ARB_17, ARB_19).
• ARF [Topic 12] - All ARB_ requirements applicable to non-qualified EAA have been addressed: ARB_01b, ARB_02, ARB_05, ARB_06, ARB_06a, ARB_06b, ARB_07, ARB_09, ARB_10, ARB_12, ARB_15, ARB_17, ARB_19, ARB_21, ARB_26, ARB_27, ARB_30, ARB_31, ARB_34.
• ETSI TS 119 472-1 - The Rulebook structure and attestation lifecycle follow this standard.
• [TS12] - Attribute definitions and transaction data processing align with TS12 published by the European Commission.
• [EMV-DPC] - The logical credential model, disclosable attribute set, and display meta-data model are derived from the EMVCo Digital Payment Credential specification, adapted to WE BUILD type identifiers and metadata claims as described in Section 2.8. The source specification's co-badged card handling is out of scope for WE BUILD (see Section 2.1).
• [HAIP] - The SD-JWT VC encoding complies with the OpenID4VC High Assurance Interoperability Profile.

2.2 Regulatory basis

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

3.1 Introduction

SCA-Card (DPC) is a simple attestation type with only top-level attributes, all of which are selectively disclosable. The attestation payload is intentionally minimal: it identifies the credential instance, the payment network, and optionally the digitised card through an opaque token reference. It never contains the PAN, the card BIN, or the last four digits; those are display-only data carried in the unsigned display meta-data object described in Section 4.6.

Unlike the other attestations of the WE BUILD SCA family, SCA-Card (DPC) does not define a sub claim. The EMVCo source model has no subject identifier; the credential_id attribute identifies the credential instance and plays that role.

Co-badged cards, cards that participate in more than one payment network, are out of scope for the WE BUILD profile of this attestation: WE BUILD supports SCA-Card (DPC) for single-network cards only, and each attestation identifies exactly one payment network. The EMVCo source specification [EMV-DPC] defines a per-badge credential model for co-badged cards; that model MAY be adopted in a future version of this Rulebook.

This document defines the attribute attestation_legal_category which SHALL have the value "non-qualified-EAA".

3.2 Mandatory attributes

3.3 Optional attributes

3.4 Conditional attributes

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

4.4 Code lists

4.5 Integrity rules

For SCA-Card (DPC) the proposed base VCT is: https://webuildconsortium.eu/sca/sca-card-dpc/1.0

This base type has claims "extends" and "extends#integrity" that point to the base SCA VCT type https://webuildconsortium.eu/sca/1.0.

Actual SCA-Card (DPC) attestations issued by a credential issuer carry an issuer-specific VCT URL such as https://issuer.bank.example/credentials/sca/card-dpc/1.0 and their metadata contains claims "extends" and "extends#integrity" pointing to the base SCA-Card (DPC) type https://webuildconsortium.eu/sca/sca-card-dpc/1.0.

Versioning of VCT types SHALL follow an x.y version model where: - x is the major version - introduces breaking changes (removing claims from metadata, renaming or repurposing claims in transaction data). - y is the minor version - introduces backward-compatible changes (adding elements, adding display claims, adding languages).

With this mechanism, integrity checks remain in place and the need for re-issuance of credentials across all wallets is minimised.

The attribute set and semantics of this attestation type are derived from the EMVCo Digital Payment Credential type com.emvco.dpc.card defined in [EMV-DPC]. Within the WE BUILD pilot, the WE BUILD VCT hierarchy above is used as the type identifier; the EMVCo identifier is referenced for semantic alignment only.

4.6 Display meta-data

Each SCA-Card (DPC) attestation is delivered together with an unsigned display meta-data object that defines how the Wallet presents the card to the User, both in the card representation in the Wallet and on the payment sheet. Providing this data with the attestation enables consistent, issuer-controlled rendering without reliance on out-of-band branding repositories. The object carries the following fields within its top-level card object:

Image resources referenced by image_url attributes MAY be provided either as externally hosted HTTPS URLs or as embedded Data URLs as defined in [RFC 2397]. Image arrays SHALL contain at least one image; when only a single image is provided, its theme value SHALL be DEFAULT, indicating that the image is suitable for any UI theme.

The display meta-data object:

• is NOT part of the signed attestation and carries no issuer signature;
• is transported in the display array of the OpenID4VCI credential response, enabling the Wallet to render the issued attestation with full visual fidelity, and MAY additionally be provided in the credential offer, enabling the User to recognise the card and give informed consent before issuance;
• is never presented to a Verifier. This is guaranteed structurally: the object is not a claim in the signed credential and display meta-data is not part of an OpenID4VP presentation.

Wallet behaviour for rendering this data is specified in Chapter 4 (Wallet display handling).

The table above defines field semantics only; the authoritative definition of the object's structure (data types, patterns, enumerations, and required fields) is the machine-readable JSON Schema published in this catalogue at data-schemas/display/sca-card-dpc-display-meta.schema.json, with a sample at data-schemas/display/sample-data/sca-card-dpc-display-meta-sample.json.

5 Formats

5.1 SD-JWT VC-based encoding

The SCA-Card (DPC) attestation supports the SD-JWT VC format as specified in [SD-JWT VC], compliant with the [HAIP] profile.

VCT (Verifiable Credential Type): https://issuer.bank.example/credentials/sca/card-dpc/1.0 (issuer-specific; MUST extend https://webuildconsortium.eu/sca/sca-card-dpc/1.0 via "extends" and "extends#integrity" claims in VCT metadata)

The machine-readable JSON Schema of the resolved claim set is published in this catalogue at data-schemas/sd-jwt/sca-card-dpc-sd-jwt.json, with a sample at data-schemas/sd-jwt/sample-data/sca-card-dpc-sd-jwt-sample.json.

IANA-registered JWT claims (not selectively disclosable):

Private claim names and SD-JWT-specific claims:

Example JWT claim set (provider-side, before issuing SD-JWT):

{
  "vct": "https://issuer.bank.example/credentials/sca/card-dpc/1.0",
  "vct#integrity": "sha256-Cp5VgPMqzU7cphGIL0aRy54scWhTiBFB1FJYDLyO94w=",
  "iss": "https://issuer.bank.example",
  "iat": 1772195095,
  "exp": 1835267095,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "f83OJ3D2xF4wK2Yp6tK2vNhbbX6YsJhBKt3vnDnNQfQ",
      "y": "x_FEzRu9w4J6v7P3cu6UytzszbmWzxubUANe0yoyl9A"
    }
  },
  "attestation_legal_category": "non-qualified-EAA",
  "_sd_alg": "sha-256",
  "_sd": [
    "X9yH4uRPd0rFgCnMq7LwKp3jZoStViEa2bDNcOIkT8s",
    "mBpQ1vYeKrDnCjHaWgFxZ5tSoUilNcT3LdR7yEhAP94",
    "kL8nJpFaOcQrBdVwXgY2eIhCmT5ZsU1RoPN6yDK7WHv"
  ]
}

Example issued SD-JWT (compact serialization, abbreviated):

eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCIsImtpZCI6Imlzc3Vlci1rZXktMSJ9
.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5iYW5rLmV4YW1wbGUiLCJpYXQiOjE3NzIxOTUwOTUs
ImV4cCI6MTgzNTI2NzA5NSwidmN0IjoiaHR0cHM6Ly9pc3N1ZXIuYmFuay5leGFtcGxlL2Ny
ZWRlbnRpYWxzL3NjYS9jYXJkLWRwYy8xLjAiLCJjbmYiOnsiandrIjp7Imt0eSI6IkVDIn19
LCJhdHRlc3RhdGlvbl9sZWdhbF9jYXRlZ29yeSI6Im5vbi1xdWFsaWZpZWQtRUFBIiwiX3Nk
X2FsZyI6InNoYS0yNTYiLCJfc2QiOlsiLi4uIl19
.
<issuer-signature>
~WyI8c2FsdC0xPiIsImNyZWRlbnRpYWxfaWQiLCJ1cm46dXVpZDo5ZjJiN2EyZS0uLi4iXQ
~WyI8c2FsdC0yPiIsIm5ldHdvcmsiLCJtYXN0ZXJjYXJkIl0
~WyI8c2FsdC0zPiIsImNhcmRfaWQiLCJtYy04YzNmMmQxYSJd

Human-readable SD-JWT payload and disclosure descriptions:

Non-selectively-disclosable claims (always present in the JWT body):

Selectively-disclosable claims (each disclosure encoded as [<salt>, <claim_name>, <claim_value>] base64url per [SD-JWT VC]):

5.2 ISO/IEC 18013-5-compliant encoding

This encoding is not supported for this attestation type. SCA-Card (DPC) SHALL be issued exclusively in the SD-JWT VC format specified in Section 3.2. Presentation when the Wallet Unit and the Relying Party are in proximity without using the internet is not required for this attestation type (see ARB_02 in [Topic 12]): all supported use cases are online remote-commerce flows.

5.3 W3C Verifiable Credentials Data Model-based encoding

This encoding is not supported for this attestation type. The attestation SHALL be issued exclusively in the SD-JWT VC format.

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

SCA-Card (DPC) is designed for the 3-party model in remote commerce: the credential issuer and the verifier are in different organisations. The verifying side is typically a merchant, PSP, or a payment system component acting on their behalf. Integration of DPC presentations into payment system rails, for example EMVCo Secure Remote Commerce (Click to Pay), is defined by the respective payment system specifications and is out of scope of this Rulebook.

Primary use cases:

1. Payment authentication with a known credential: The verifier already holds a reference to the digitised card (e.g. token on file or recognised returning consumer) and requests a presentation of the specific attestation, typically by credential_id.
2. Authenticated guest checkout with credential discovery: The verifier does not know the card. The presentation request filters by supported networks, the User selects a card in the Wallet, and the disclosed card_id gives the verifier the network token reference needed to route the transaction.

Both use cases provide multi-factor authentication through device biometrics or PIN plus the device-bound key, supporting PSD2 Strong Customer Authentication. SCA-Card (DPC) is exclusively used in presentation scenarios where transaction data is present in the presentation request.

Relying Party obligations:

• The Relying Party SHALL verify the issuer signature and the cnf key binding (KB-JWT) before accepting the attestation.
• The Relying Party SHALL verify that presented transaction data is bound to the attestation as specified in [Topic 20] and [TS12] ("sign what you see": the Wallet incorporates the payment details shown to the User into the data signed by the device-bound key).
• Verification of a PID alongside this attestation is not required.

Presentation requirements:

• SCA-Card (DPC) SHALL be presented online using OID4VP; presentation MAY be invoked through the W3C Digital Credentials API.
• Transaction data MUST be present in all presentation requests (see [Topic 20]).
• The Wallet SHOULD respect VC metadata published by the Issuer at the VCT metadata endpoint.

Wallet requirements (normative):

• The Wallet SHALL present each matched attestation as a single card on the payment sheet.
• The Wallet SHALL return exactly one attestation, the selected card's, as the response to the credential query, with the key binding mechanism binding it to the transaction data.

Wallet display handling (normative):

• The Wallet SHOULD render the card in the Wallet UI and on the payment sheet using the display meta-data delivered at issuance (Section 4.6), without relying on out-of-band branding repositories.
• For themed images (card_art and branding logos), the Wallet SHOULD select the image variant matching the active UI theme and SHALL fall back to the DEFAULT variant when no theme-specific image is provided.
• The Wallet SHALL support image resources provided as externally hosted HTTPS URLs as well as embedded Data URLs per [RFC 2397].
• When retrieving externally hosted images, the Wallet SHOULD take measures to prevent unintended disclosure of User information, for example by avoiding transmission of identifying headers or by using privacy-preserving fetch mechanisms.

Device binding:

• This attestation SHALL be device-bound (ARB_34 in [Topic 12]).
• The device binding key SHALL be attested at AVA_VAN.4 or higher.
• Each credential instance SHALL have its own unique binding key pair (IR-03).
• The attestation MAY be cryptographically bound to the holder's PID. If so, cryptographically_bound_to SHALL carry the value "urn:eudi:pid:1". Note that such binding weakens the unlinkability property provided by per-instance keys and SHOULD be avoided unless required by the deployment.

Issuer of SCA-Card (DPC) is - for the purpose of WE BUILD - the card issuer or an entity issuing credentials on its behalf (the Credential Issuer in [EMV-DPC] terms).

Before issuance, the Issuer SHALL check Wallet eligibility:

• Wallet provider is trusted for this purpose via a trust list.
• Wallet Unit is in operational state with valid WUA/WIA and PID.
• Wallet Unit has an eligible WSCD available at AVA_VAN.4 or higher.
• The user identified by this Wallet Unit is the same user authenticated into the issuer's environment.

When issuing the attestation, the Issuer SHALL:

• Use a sender-constrained token (DPoP) to ensure that only the requesting Wallet may receive the issued credential.
• Ensure that the attestation is device-bound with sufficient secure storage (AVA_VAN.4 or higher).
• Deliver the display meta-data object (Section 4.6) in the display array of the credential response, and MAY additionally include it in the credential offer to support user recognition before issuance.

After receiving the attestation, the Wallet SHOULD notify the Issuer of successful acceptance.

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

SCA-Card (DPC) attestations are long-lived by definition: the attestation is provisioned once and remains valid for an extended period, typically aligned with the lifecycle of the underlying digitised card. The validity period is expressed through the exp metadata.

The revocation mechanism for this attestation type is TBD and will be defined in a future version of this Rulebook.

9 Presentation

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

9.4 Presentation lifecycle

SCA-Card (DPC) SHOULD be presented when the presentation request comes from a verifier participating in a payment transaction, with payment transaction data attached as described in [TS12].

The following DCQL examples illustrate the two selection patterns in an OpenID4VP request. A Wallet SHALL treat an attestation as matching a requested VCT value when its vct claim or any type in its extends chain equals that value.

Query by Credential ID (known-card scenario): requests a specific attestation and disclosure of credential_id and network.

{
  "credentials": [
    {
      "id": "dpc",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://webuildconsortium.eu/sca/sca-card-dpc/1.0"]
      },
      "claims": [
        { "path": ["credential_id"], "values": ["urn:uuid:9f2b7a2e-3b74-4a0d-9b1a-0e6a91f5d2c8"] },
        { "path": ["network"] }
      ]
    }
  ]
}

Query by supported network (guest checkout): filters on the network claim. Because every attestation carries a single-valued network claim, this uses standard DCQL values semantics. The Wallet shows each matching card once; after the User selects a card, the Wallet presents exactly one attestation and discloses only the requested attributes.

{
  "credentials": [
    {
      "id": "dpc",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://webuildconsortium.eu/sca/sca-card-dpc/1.0"]
      },
      "claims": [
        { "path": ["network"], "values": ["mastercard", "visa"] },
        { "path": ["credential_id"] },
        { "path": ["card_id"] }
      ]
    }
  ]
}

10 Trust Framework

SCA-Card (DPC) is a non-qualified EAA. The trust anchor mechanism for this attestation type is TBD and will be defined in a future version of this Rulebook. This includes the mechanism through which Relying Parties obtain the trust anchor used to verify the attestation and the mechanism through which they establish that an Issuer is authorized to issue this attestation type, for example a sector-specific issuer accreditation scheme such as an EMVCo-operated issuer root programme discussed in [EMV-DPC]-related work.

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References