EUDI credential issuance: turning enterprise records into a working service

An organization may already hold the information someone needs to prove: a professional qualification, a membership or an employment relationship. Making that information available through a wallet requires more than signing a document. The issuer service must know which record is authoritative, who may receive the credential and how later changes affect what was issued.

That creates a concrete engineering project for companies preparing wallet-based services. It connects a system of record to an issuance workflow, a signing boundary and an operational lifecycle. The useful question for procurement is not “can this team issue a credential?” It is “can this team keep the issued claim consistent with our business process?”

This article uses a fictional professional training company whose learning platform records completed qualifications. Its proposed first release lets eligible learners request a wallet credential for one qualification. The examples are design proposals, not claims about a delivered su.engineering engagement or guaranteed acceptance by every EUDI wallet.

Establish the issuer role and the intended use

Before building, identify who is making the claim and which organizations intend to rely on it. A company's record of course completion and a qualified electronic attestation are not interchangeable labels.

The Commission's issuer guidance distinguishes different issuer and attestation categories, including qualified providers. Choosing a technical issuance protocol does not itself confer qualified status or make a credential acceptable in every ecosystem. Establish the relevant role, attestation scheme and production onboarding requirements with the parties responsible for them. Commission guidance for issuers

For the fictional training company, start with a named qualification, an identified set of intended verifiers and an agreed credential profile. Confirm whether the target wallets and verifiers support that profile before promising the commercial feature.

This decision creates a useful project boundary. The company owns the qualification rules and authority to attest them. An engineering contractor can implement how eligibility is evaluated, how the credential is issued and how its lifecycle is operated. If another provider supplies a trust service, document that dependency rather than treating it as a feature the application team can manufacture.

Make the authoritative record explicit

An enterprise rarely has one perfectly clean record. The learning platform may record completion, a finance system may record payment, and a support tool may contain a correction. Decide which fields are relevant to issuance and which system controls each field.

For our example, a qualification record needs a stable internal identifier, a subject association, the qualification code, the completion state and a revision. The exact fields are a business decision. Do not copy the entire learner profile into the credential simply because the database query can return it.

Document how a source record becomes eligible. Perhaps a completed assessment still requires an administrator's approval. Perhaps a support correction temporarily suspends issuance. Those states must be represented in the integration, not inferred from a loosely named active flag.

Agree how fresh the source data must be. If an event says a learner passed but the current record says the result was corrected, which one wins? For the proposed system, the issuance decision reads the current authoritative revision and records that revision with the issuance record. An event starts work; it does not automatically authorize a credential.

The contractor should deliver a field mapping, eligibility rules with test fixtures and an explicit treatment of missing or conflicting data. These artifacts often reveal more project risk than the initial protocol setup.

Separate the source adapter from the issuer

Keep business-specific record handling behind a narrow interface. The issuer should not accumulate direct knowledge of every learning-platform table or help-desk status code.

Learning platform / qualification records
                  |
           Source adapter
                  |
      Eligibility and issuance ledger
                  |
       Credential issuance service <----> Wallet
                  |
           Signing boundary
                  |
         Credential status service

The source adapter produces a normalized decision using the company's rules. The issuance ledger records attempts and issued instances. The wallet-facing service handles the selected issuance protocol and credential format. The signing boundary controls the use of issuer keys. Status infrastructure, where the chosen scheme uses it, supports later lifecycle changes.

These may be modules in one deployment rather than separate microservices. The important separation is responsibility and testability. A small project does not become better merely because its diagram has more network hops.

The EUDI reference issuer's documentation describes adding attestations through configuration and implementation work. Use that as a component-level starting point, while keeping the company's data and eligibility adapter explicit. EUDI reference implementation: adding attestations

An acceptance test should be able to replace the learning platform with synthetic fixtures and demonstrate the same eligibility decisions without touching production learner data.

Connect issuance authorization to the right person

A logged-in portal session, a qualification record and a wallet request represent different things. The integration must establish the intended association between them. Possession of a link should not accidentally become sufficient authority to receive somebody else's credential.

OpenID4VCI 1.0 defines authorization-code and pre-authorized-code issuance flows. Its pre-authorized flow needs protections against misuse of the code; the specification also provides a transaction-code mechanism. Select and configure the flow for the actual journey, including the applicable wallet and credential profile. OpenID4VCI 1.0 final specification

For the training portal, a starting design could require the learner to authenticate to the existing account before initiating issuance for an eligible qualification. The backend creates a bounded issuance session associated with that account and source record. The wallet-facing flow then establishes the required authorization and proofs for the agreed profile.

Review the support path too. If an administrator can trigger an offer, what confirms the recipient? Can a support employee see or forward a sensitive offer? Which action is recorded, and how is access revoked? A technically correct wallet exchange does not correct an unsafe administrative process.

Ask for explicit tests involving two learners, two browser sessions and deliberately exchanged offer links. The expected result should be written before implementation. Do not leave the recipient-binding assumption hidden inside a frontend button.

Design retries around issued instances, not HTTP requests

Enterprise integrations retry. A queue redelivers an event, a browser refreshes, or a worker times out after signing succeeds. “We only call this endpoint once” is not a production design.

In the example system, distinguish the business entitlement from an issued credential instance. One qualification may legitimately produce several instances over its lifecycle, depending on the chosen profile and reissuance policy. At the same time, a duplicate delivery of one internal issuance command should not create uncontrolled duplicates.

Use a stable internal operation identifier and track the source revision, intended subject association and resulting instance references. Make concurrent handling of the same operation deterministic. Record whether an instance was prepared, issued, delivered where observable, or left in an uncertain state requiring reconciliation.

If the source system can take time to approve a qualification, choose an explicit waiting model. OpenID4VCI includes deferred issuance; support must be checked for the selected wallet/profile combination. An internal approval queue and a protocol-level deferred response are different responsibilities, even if the implementation connects them. OpenID4VCI deferred issuance

Require a crash-recovery demonstration: stop a worker after a credential has been signed but before the operation is marked complete. Restart it and explain exactly how the system reconciles the result. This is a better acceptance exercise than testing only successful requests with no interruptions.

Treat corrections and status changes as first-release work

A qualification may be entered incorrectly, withdrawn or superseded. A learner may lose a device. The issuer needs documented behavior for each event.

Deleting an entry in the learning platform does not erase a credential already held in a wallet. Design the response according to the credential scheme: changing status, allowing expiry, issuing a corrected instance or another defined mechanism. Confirm how intended verifiers consume that information. Do not promise immediate invalidation unless the complete verification path supports it.

For the training example, define the path from an approved correction to every affected issued instance. Record the relevant source revision and instance identifiers so the system can find them. If an update cannot be propagated, surface an operational exception rather than quietly reporting success.

Specify what happens when lifecycle events arrive out of order. An older “qualification approved” message should not overwrite a later withdrawal. Decide how operators replay failed work safely and how they can distinguish pending propagation from completed propagation.

Recovery deserves a separate rule. Reissuing to a replacement wallet can require new authentication and authorization. It should not be triggered solely by a caller supplying an old credential identifier. The support runbook must explain who can approve recovery and what evidence is required.

Put key ownership and operations in the statement of work

Agree who owns the production signing keys, which service may use them and how access is audited. The implementation should reference the client's approved key-management boundary rather than distributing private keys through developer configuration files.

Plan rotation before launch. Identify how newly issued instances reference the new signing material and how verification of existing instances remains supported according to the chosen format and trust scheme. Distinguish planned rotation from a compromise response; they have different operational consequences.

Ask for a runbook covering failed signing requests, unavailable source systems, delayed status updates and unexpectedly high issuance volume. Give each alert a named owner and a recovery action. “Monitor the service” is not enough guidance for the client's operations team at handover.

Log operation references and bounded outcomes rather than raw credentials or issuance secrets. The team troubleshooting delivery should be able to follow an attempt without gaining unnecessary access to the learner's attributes.

Buy components where useful; commission the missing integration

A commercial issuer may provide protocol handling, signing integration or lifecycle features. A reference implementation may provide reusable foundations. Assess either against the qualification profile, target wallets, deployment model, exportability of records and operational requirements.

The company's distinctive work usually sits around those components: mapping the source records, establishing eligibility, associating the recipient, handling corrections and integrating support. An external engineering team is useful when it can own that bounded integration and transfer the implementation back to the client.

Ask bidders to separate component costs, custom integration, testing, operational setup and ongoing maintenance. Require them to state which production dependencies are assumed to exist. A proposal that includes a working issuer but excludes access to authoritative data may leave the company's main problem unsolved.

Define a handover that proves the service works

For the first qualification, the acceptance pack should include a versioned credential mapping, source-system contract, supported-wallet matrix, deployment configuration and synthetic fixtures. It should demonstrate:

• Ineligible and ambiguous records do not produce credentials.
• A learner cannot obtain another learner's qualification through a changed identifier or exchanged offer.
• Repeated internal commands are handled consistently, including concurrent processing.
• A crash during issuance can be reconciled without losing track of issued instances.
• A source correction reaches the applicable lifecycle mechanism, with failures visible to operators.
• Rotation and recovery follow the agreed procedure without improvised production access.
• Logs and support screens expose only their agreed diagnostic information.

The handover should include source code, dependency versions, test results and a runbook in systems the client controls. Where external conformance or trust onboarding is required, name the owner and evidence separately. A passing internal test suite does not confer a regulatory status.

Our identity and EUDI engineering practice works with teams defining these integrations. Bring the authoritative system, the credential you want to issue, the intended recipients and the organizations expected to accept it. Let's scope the issuer service together.

If your company needs to consume wallet evidence instead, see EUDI wallet integration for an existing customer platform.