Transaction Data Profiles

transaction-data-profiles.conf defines the OpenID4VP transaction_data types Wallet API v2 accepts when previewing, presenting, building, or sending authorization responses.

The transaction-data-profiles optional feature is enabled by default. When enabled, the wallet:

  • Loads type identifiers into its TransactionDataTypeRegistry
  • Rejects authorization requests that carry unknown transaction_data.type values
  • Exposes the configured profiles via discovery

Discovery Endpoint

GET /transaction-data-profiles

Returns the configured List<TransactionDataProfile> (type, displayName, fields).

Disable the feature (empty registry, no discovery route) by listing it under disabledFeatures in _features.conf.

mDoc issuance grant: For mso_mdoc credentials, registering a type here is not enough for the holder to device-sign it. The credential's MSO must authorize that type via KeyAuthorizations, which Issuer2 sets from authorizedTransactionDataTypes. SD-JWT VC presentations bind transaction data in the KB-JWT and do not use that field.

File Location

waltid-services/waltid-wallet-api2/config/transaction-data-profiles.conf

Docker Compose ships the same file under docker-compose/wallet-api2/config/.

Fields

transactionDataProfiles

Array of Objects — List of recognized transaction data types. Each profile defines:

FieldTypeDescription
typeStringRequired. The transaction data type identifier. Used as the type field in transaction data entries and as the namespace for mdoc DeviceSigned binding.
displayNameStringHuman-readable name for UIs and discovery. Defaults to type if omitted.
fieldsArrayExpected top-level field names for documentation/UI. Nested payloads (e.g. SCA) can declare a container such as ["payload"].

Built-in Profiles

transaction-data-profiles.conf
transactionDataProfiles = [
  {
    type = "org.waltid.transaction-data.payment-authorization"
    displayName = "Payment Authorization"
    fields = ["merchant_name", "amount", "currency"]
  },
  {
    type = "org.waltid.transaction-data.account-access"
    displayName = "Account Access"
    fields = ["account_identifier", "access_scope"]
  },
  {
    type = "urn:eudi:sca:payment:1"
    displayName = "SCA Payment"
    fields = ["payload"]
  },
  {
    type = "payment_card"
    displayName = "Payment Card"
    fields = ["merchant_name", "amount"]
  }
]

Keep Wallet API v2 types aligned with Verifier2 and (for mDocs) Issuer2 authorizedTransactionDataTypes. See the shared Verifier2 transaction-data profiles guide for request examples and custom type instructions.

Runtime overlay mutations are not exposed on Community Wallet API v2. Durable types live in transaction-data-profiles.conf. Per-service create, replace, and delete live on Enterprise Wallet2 and Verifier2. Wallet API v1 remains discovery-only (GET /transaction-data-profiles).

Community Verifier2 session create does not apply a type allowlist. Keep Wallet2 types aligned with the verifier's HOCON so the wallet can present the types a verifier actually requests.

Last updated on August 19, 2026