EAASD-JWT VCmdoc

Attestation Rulebook for attestations of type SCA IBAN

Category: non-qualified EAA

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

• Author(s):
  • Filip Hladký, Bank iD CZ, filip@bankid.cz
  • Stefan Kauhaus, Visa, kauhauss@visa.com

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-IBAN attestation specifies Account level SUA attestation described in TS12 published by European Commission. SCA-IBAN attestation represents User and their account, and it is used in 3rd party Payment initiation with PISP-captured SCA.

More over SCA-IBAN may be used in the same scenarios as SCA-user, that is using EUDI Wallet for authentication and risk operation authorization in their online banking or banking mobile application. In this document we specify attributes, allowed formats, and processing rules for this attestation. We also specify SD-JWT metadata for SD-JWT credential format since those metadata are critical for correct processing of presentation requests with attached transaction data.

Attestation rulebook is aligned with ETSI TS 119 472-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 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), Attestation attributes and metadata satisfy the requirements of Annex V (QEAA) and Annex VII (PuB-EAA) as applicable.
• ARF [Topic 12], All ARB_ requirements referenced in the template have been addressed: ARB_01b, ARB_02, ARB_05, ARB_06, ARB_06a, ARB_06b, ARB_07, ARB_09, ARB_10, ARB_11–ARB_21, ARB_26–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.
• [HAIP], The SD-JWT VC encoding complies with the OpenID4VC High Assurance Interoperability Profile.
• [ISO/IEC 18013-5], The mdoc encoding follows the ISO mobile document standard.

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-IBAN is a simple attestation type with only top-level attributes, some of which are selectively disclosable. It is designed to support various use cases in Banking, most importantly SCA in Open Banking for both ASPSP and PISP-captured scenarios. In addition, SCA-IBAN is designed to support authentication and user confirmation in banking applications.

Attestation is based on TS12 requirements which are refined for WE BUILD.

Unlike SCA-User, SCA-IBAN does support selective disclosure.

This document defines the attribute attestation_legal_category which SHALL have the value "QEAA", "PuB-EAA", or "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

This attestation does not use any code lists.

4.5 Integrity rules

For SCA-IBAN the proposed base VCT is: https://webuildconsortium.eu/sca/sca-iban/1.0

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

Actual SCA-IBAN attestations issued by a bank carry an issuer-specific VCT URL such as "https://issuer.bank.cz/credentials/sca/iban/1.0" and their metadata contains claims "extends" and "extends#integrity" pointing to the base SCA-IBAN type https://webuildconsortium.eu/sca/sca-iban/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.

5 Formats

5.1 SD-JWT VC-based encoding

The SCA-IBAN 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.cz/credentials/sca/iban/1.0 (issuer-specific; MUST extend https://webuildconsortium.eu/sca/sca-iban/1.0 via "extends" and "extends#integrity" claims in VCT metadata)

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):

{
  "iss": "https://issuer.bank.cz",
  "iat": 1748736000,
  "exp": 1751328000,
  "vct": "https://issuer.bank.cz/credentials/sca/iban/1.0",
  "vct#integrity": "sha256-abc123def456...",
  "sub": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  },
  "attestation_legal_category": ""non-qualified-EAA"",
  "status_list": {
    "idx": 12,
    "uri": "https://issuer.bank.cz/statuslists/1"
  },
  "_sd_alg": "sha-256",
  "_sd": [
    "X9yH4uRPd0rFgCnMq7LwKp3jZoStViEa2bDNcOIkT8s",
    "mBpQ1vYeKrDnCjHaWgFxZ5tSoUilNcT3LdR7yEhAP94",
    "kL8nJpFaOcQrBdVwXgY2eIhCmT5ZsU1RoPN6yDK7WHv",
    "eA3hKpNdRqWmXvZcY7tJfOiSgBL1Uo2nCu6DrsP8FT4",
    "vT5cY2RdXoNpKfHaQ9gBmJwLe6PiUs3Cn1rODkA7ZI8",
    "qZ4bW7MdPlJnFhR3aOeKvGcT9XoA6sU2Ct1YiDB5Np8",
    "dR6xK3WoMvCfQpHnL2bY5ZjA9Ts4PuN1gOe7iBSUDa0"
  ]
}

Example issued SD-JWT (compact serialization):

eyJhbGciOiJFUzI1NiIsInR5cCI6InZjK3NkLWp3dCIsImtpZCI6Imlzc3Vlci1rZXktMSJ9
.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5iYW5rLmN6IiwiaWF0IjoxNzQ4NzM2MDAwLCJleHAiOj
E3NTEzMjgwMDAsInZjdCI6Imh0dHBzOi8vaXNzdWVyLmJhbmsuY3ovY3JlZGVudGlhbHMvc2Nh
L2liYW4vMS4wIiwidmN0I2ludGVncml0eSI6InNoYTI1Ni1hYmMxMjMuLi4iLCJzdWIiOiJ1cm4
6dXVpZDoxMjNlNDU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2MTQxNzQwMDAiLCJjbmYiOnsiandri
jp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1Zv
SElQMUlMaWxEbHM3dkNlR2VtYyIsInkiOiJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVmZ1
ZWNDRTZ0NGpUOUYySFpRIn19fSwiYXR0ZXN0YXRpb25fbGVnYWxfY2F0ZWdvcnkiOiJRRUFBIiw
iX3NkX2FsZyI6InNoYS0yNTYiLCJfc2QiOlsiLi4uIl19
.
<issuer-signature>
~WyJyYW5kb20xIiwibWFza2VkX2liYW4iLCJDWjU1KioqKioqKioqKio4NzQ1Il0
~WyJyYW5kb20yIiwiaWJhbiIsIkNaNTUwODAwMDAwMDAwMTIzNDU2Nzg5OSJd
~WyJyYW5kb20zIiwibmF0aW9uYWxfYmFua19jb2RlIiwiMDgwMCJd
~WyJyYW5kb200IiwiYmljIiwiR0lCQUNaUFgifQ
~WyJyYW5kb201IiwiY3VycmVuY3kiLCJDWksiXQ

Human-readable SD-JWT payload and disclosure descriptions:

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

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

5.2 ISO/IEC 18013-5-compliant encoding

The SCA-IBAN attestation supports the mdoc format specified in ISO/IEC 18013-5.

Document type: eu.webuildconsortium.sca.iban.1

Encoding conventions:

• tstr, uint, bstr, bool, and tdate are CDDL representation types defined in [RFC 8610].
  • tstr SHALL be encoded in UTF-8 and SHALL support the full Unicode range (per [RFC 8949]).
  • All tstr attributes SHALL have a maximum length of 150 characters.
  • full-date is defined as full-date = #6.1004(tstr) where tag 1004 is specified in [RFC 8943].
  • A tdate attribute SHALL contain a date-time string as specified in [RFC 3339] (per [RFC 8949] §3.4.1).
  • A full-date attribute SHALL contain a full-date string as specified in [RFC 3339] (per [RFC 8943]).
  • Fractions of seconds SHALL NOT be used.
  • A local offset from UTC SHALL NOT be used; the time-offset SHALL be "Z".
  • The following canonical CBOR rules (per [RFC 8949] §4.2) SHALL be implemented:
    • Integers (major types 0 and 1) SHALL be as small as possible.
    • The expression of the length in a bstr, tstr, array, or map SHALL be as short as possible.
    • Indefinite-length items SHALL be made into definite-length items.

Attribute encoding table:

Example mdoc (CBOR diagnostic notation):

{
  "version": "1.0",
  "documents": [{
    "docType": "eu.webuildconsortium.sca.iban.1",
    "issuerSigned": {
      "nameSpaces": {
        "eu.webuildconsortium.sca.iban.1": [
          { "digestID": 1, "random": h'a1b2c3d4', "elementIdentifier": "sub",
            "elementValue": "urn:uuid:123e4567-e89b-12d3-a456-426614174000" },
          { "digestID": 2, "random": h'e5f6a7b8', "elementIdentifier": "masked_iban",
            "elementValue": "CZ55***********7899" },
          { "digestID": 3, "random": h'c9d0e1f2', "elementIdentifier": "iban",
            "elementValue": "CZ5508000000001234567899" },
          { "digestID": 4, "random": h'a3b4c5d6', "elementIdentifier": "national_bank_code",
            "elementValue": "0800" },
          { "digestID": 5, "random": h'e7f8a9b0', "elementIdentifier": "bic",
            "elementValue": "GIBACZPX" },
          { "digestID": 6, "random": h'c1d2e3f4', "elementIdentifier": "currency",
            "elementValue": "CZK" },
          { "digestID": 7, "random": h'a5b6c7d8', "elementIdentifier": "attestation_legal_category",
            "elementValue": "non-qualified-EAA" }
        ]
      },
      "issuerAuth": << IssuerAuth COSE_Sign1 structure >>
    }
  }],
  "status": 0
}

Attribute values in the example:

5.3 W3C Verifiable Credentials Data Model-based encoding

This Rulebook does not define a W3C Verifiable Credentials Data Model encoding for this attestation type.

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-IBAN is primarily designed for the 3-party model where the issuer and verifier are in different organisations. The verifier (Relying Party) is typically a PISP or Merchant acting as a PISP, which captures SCA via the Wallet and forwards it to the ASPSP with the payment.

Primary use cases:

1. PISP-captured SCA for payment initiation (primary): The Wallet presents the SCA-IBAN attestation with transaction data to a PISP, which forwards it to the ASPSP. Processing of transaction data follows [TS12].
2. ASPSP-captured SCA (2-party model): The issuing bank may allow SCA-IBAN to be used directly in its own mobile/web banking application, subject to VC metadata permission. Same rules as for SCA-User apply.
3. User authentication and operation authorization in the issuing bank's banking applications.

SCA-IBAN 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 before accepting the attestation.
• The Relying Party SHALL check the status_list claim if present to verify that the attestation has not been revoked.
• The Relying Party SHALL verify that presented transaction data is bound to the attestation as specified in [Topic 20] and [TS12].
• The Relying Party SHOULD verify that the aud claim, if present, includes the RP's own identifier.
• Verification of a PID alongside this attestation is not required.

Presentation requirements:

• SCA-IBAN SHALL be presented online using OID4VP.
• Transaction data MUST be present in all payment-initiation presentation requests (see [Topic 20]).
• In the SD-JWT encoding, the Wallet SHOULD respect VC metadata published by the Issuer at the VCT metadata endpoint.

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.
• The attestation MAY be cryptographically bound to the holder's PID. If so, cryptographically_bound_to SHALL carry the value "eu.europa.ec.eudi.pid.1" (ISO/IEC 18013-5) or "urn:eudi:pid:1" (SD-JWT VC).

Issuer of SCA-IBAN is, for the purpose of WE BUILD, a Bank acting as ASPSP in PSD2.

Before issuance, the Bank 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 via 2FA into the banking environment.

Eligibility checks MAY be performed by:

• Requesting WUA and WIA and validating the signing certificate and key attestations.
• Requesting a PID and matching its attributes with the authenticated user's data.

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.
• Provide means to refresh the attestation (i.e., refresh tokens).
• Ensure that the attestation is device-bound with sufficient secure storage (AVA_VAN.4 or higher).
• Include or publish information about allowed verifiers; the aud claim MAY be used for this purpose.

Deferred issuance is not recommended, the user is in the loop and banks should be able to process the issuance request online.

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-IBAN attestations are intended to be short-lived (validity period ≤ 24 hours for active payment use) combined with a token refresh mechanism at the Issuer.

For attestations with a validity period exceeding 24 hours, the Issuer SHALL implement revocation using the Attestation Status List mechanism referenced in the status_list claim, in accordance with the Technical Specification to be specified by the Commission (currently tracked as draft-ietf-oauth-status-list-17).

Relying Parties SHALL check the status_list reference when present and reject attestations whose status indicates revocation or suspension.

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-IBAN SHOULD be presented when the presentation request comes from a Verifier acting as a PISP in the PSD2 scheme with payment transaction data as described in [TS12].

10 Trust Framework

Trust anchor mechanisms depend on the legal categorisation of the attestation:

• QEAA: The Relying Party obtains the Issuer's trust anchor from the applicable EU Trusted List and uses it to verify the attestation or signing certificate chain. Intermediate certificates are permitted.
• PuB-EAA: The Relying Party first verifies the Issuer's signature using the PuB-EAA Provider certificate issued by a QTSP, then verifies that certificate against the QTSP Trusted List.
• non-qualified EAA: The Issuer SHALL publish a machine-readable trust anchor at a URL referenced in the vct metadata document. Relying Parties SHALL use this URL to retrieve the trust anchor and verify issuer authorization.

In all cases, the Issuer MAY use intermediate signing certificates. The trust anchor SHALL be the root certificate on the applicable Trusted List.

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