The EUDI Reference Issuer now publishes a Learning Credential as an SD-JWT Verifiable Credential. Its Type Metadata defines the credential type urn:eu.europa.ec.eudi:learning:credential:1 and includes an achievement_title claim for the official title of a micro-credential or course. That gives wallet and relying-party teams a concrete credential type to explore together.
Learning credentials are only one possible use of an electronic attestation of attributes (EAA). The European Commission describes non-qualified EAAs as suitable for less-sensitive documents such as a gym membership card or train ticket. A private service could also explore a wallet-based proof of loyalty-program membership or tier, provided the issuer, wallet, and verifier support a compatible credential profile. That is a use case to test, not a standard loyalty credential that every wallet already accepts. The Commission's wallet overview explains the distinction between EAAs, qualified EAAs, and public EAAs.
For a verifier, a useful first experiment is to ask whether a person holds a particular learning achievement without starting with a broad identity profile. The verifier can select the achievement title in its request. The published Type Metadata marks achievement_title as mandatory and sd: never, which means it is not selectively disclosable. A wallet may also present other required fields, so the request should not be described as guaranteeing that only one value is disclosed.
A focused flow for an early pilot
DLBR EID includes an experimental Learning Credential flow that requests the achievement_title claim from the EUDI Learning Credential SD-JWT VC. The flow stays alongside other experimental credential options, and is available only when the relying-party policy allows the exact credential type and claim for the selected issuer and intended use. Because the title is marked non-selective, the wallet may disclose other mandatory claims in the credential too.
This is a starting point for interoperability testing, not a production-readiness claim. Wallet support, issuer configuration, relying-party registration, and the credential's use in a particular service all need to be checked in the target environment. Teams should also review the credential's Type Metadata to understand which data is selective and which data the issuer marks as required.
What product and compliance teams can test
- Can the wallet receive and display the Learning Credential request clearly?
- Does the relying-party policy allow only the credential type and claims needed for the intended purpose?
- What issuer-required data accompanies the selected achievement title?
- How does the verification result fit the service's existing qualification review and fallback process?
- Which registration and data-protection requirements apply to the service and market?
These checks help teams evaluate the customer experience and data boundaries before deciding whether a credential-based qualification check fits a real workflow.
Private EAA can cover everyday membership proofs
A loyalty or membership flow should start with the service decision, not a broad customer profile. If the service only needs to know whether a membership is active, its request should ask for that issuer-defined status claim rather than a member number, purchase history, or unrelated identity attributes. The issuer controls the credential's claim names and disclosure behavior, so the verifier must check the issuer's metadata and the actual wallet response instead of assuming a claim is selectively disclosable.
The legal and trust category matters too. The Commission distinguishes non-qualified EAAs from qualified EAAs and public EAAs: those categories have different assurance and legal effects. A non-qualified private-sector EAA is not automatically equivalent to a paper document or a public-sector attestation. The relying party still needs to assess the issuer, the credential profile, the request purpose, and the evidence required for its own decision. The Commission's EAA FAQ describes the categories and issuance roles.
What trust-list standards do—and do not—establish
ETSI TS 119 602 defines a data model for lists of trusted entities and can be applied to different approval schemes. Its EUDI-specific Annex H, however, profiles a list of providers that issue public-sector EAAs. The European Commission's October 2025 mDL providers-list draft is a separate profile for the narrower task of identifying mDL providers. Those scoped lists do not amount to a universal directory of private EAA issuers, nor do they define a standard set of claims for loyalty cards.
For a private EAA use case, issuer trust and credential semantics therefore remain explicit configuration choices: identify the issuer, allow the exact credential type and claims for the intended purpose, and fail closed when that trust or policy is missing. The credential proves only the attributes its issuer attests; the relying party remains responsible for deciding what those attributes mean for access, benefits, or eligibility.
The current boundary
The Learning Credential flow in DLBR EID is experimental. It is intended for controlled integration and interoperability testing with compatible wallets and issuers. It does not establish that a qualification is recognised for a regulated profession, replace a formal credential review, or make an employment or admission decision for the relying party.
The EUDI Learning Credential Type Metadata is published in the EUDI Reference Issuer repository. The EUDI Reference Verifier documentation also lists the Learning Credential VCT among its supported attestation types. Check the current wallet and issuer behavior in your own test environment before relying on the flow.