Verify the credential, not the badge image

The European Learning Model describes learning data. A European Digital Credential adds an application profile, holder-specific claims, and an electronic seal. A useful verification API checks each layer independently and never turns technical validity into an unsupported claim of recognition.

Separate model from proof Scope a credential flow

Four layers answer four different questions

The Commission describes ELM as an ontology whose application profiles add rules for concrete uses such as credentials. The EDC infrastructure then adds issuance, storage, sharing, and verification. Conflating those layers produces a checkmark that cannot explain what was actually tested. See the official ELM introduction and EDC overview.

ELM ontology

Can the concepts and relationships represent this learning claim—people, organisations, achievements, activities, assessments, entitlements, specifications, and accreditation?

Application profile

Does this concrete use meet the required classes, properties, cardinalities, datatypes, and controlled-list constraints for the declared credential profile and version?

EDC trust envelope

Is the original holder-specific credential intact, electronically sealed by the stated legal person, within validity, and not revoked according to the available evidence?

Relying-party policy

Does the verified claim satisfy this employer, university, regulator, or recognition body's own rules for purpose, level, issuer, accreditation, recency, and identity?

Policy status matters

Binding law

The Europass Decision establishes the EU framework. eIDAS governs electronic-seal legal effects and requirements. GDPR applies when the workflow processes personal data. Their duties depend on role and facts.

Non-binding recommendation

The Council's 2022 micro-credentials Recommendation supplies a common definition, standard elements, and design principles. Adoption can still be made consequential by national or institutional rules.

Technical specification and service

ELM, its application profiles, controlled vocabularies, and EDC software create interoperability. Conformance helps exchange data; it is not a general legal-compliance or recognition certificate.

Primary legal references: the Europass Decision, eIDAS Regulation, and GDPR.

Preserve every verification check

Europass exposes format, seal, owner, revocation, accreditation, and validity as distinct checks. Model them independently, retain why a check was skipped or unavailable, and record when and with which verifier it ran. A single boolean discards the evidence a reviewer needs. The official list is described in the Europass verification guidance.

Check	Evidence to preserve	Do not infer
Input and format	Original bytes or authorized reference, media type, digest, parser result, declared contexts, ELM version, application profile, constraint violations, and unsupported extensions.	Syntactically valid JSON-LD is not necessarily an EDC, and a readable PDF is not the verifiable source artifact.
Electronic seal	Integrity result, signer identity from the certificate, certificate chain, trust source, validation time, algorithm, signing-time evidence, and precise failure reason.	A logo, issuer name in payload data, or unsigned claim proves neither origin nor integrity.
Revocation	Credential revocation result where supported, certificate-status evidence, source, freshness, timeout behavior, and whether the check was applicable or reachable.	A network timeout means indeterminate—not valid—and an old result is not current proof.
Validity	Issued, valid-from, expiration, and check timestamps; clock policy; timezone normalization; and whether the credential is not yet valid or expired.	Validity dates do not establish that learning remains professionally current or accepted by a relying party.
Owner	Subject identifiers available in the credential, presentation or account context, the matching method, assurance level, minimization rules, and mismatches.	A matching display name alone proves that the presenter is the learner identified by the credential.
Accreditation	Whether accreditation is required for this claim, matching issuer and qualification, jurisdiction, scope, status, validity period, data source, and unresolved ambiguity.	No accreditation result automatically invalidates informal or non-accredited learning, or that a seal proves authorization to award a regulated qualification.

Use more than pass and fail

Give each check a stable state such as pass, fail, warning, not applicable, skipped, or indeterminate. Reserve the top-level outcome for a documented aggregation rule. Keep any admission, hiring, credit transfer, or professional-recognition decision in a separate policy object owned by the relying organization.

Where authorization matters, use the Commission's explanation of accreditation checks in EDC as the starting boundary—not a universal pass requirement.

Validate the learning claim, not only its container

Annex I of the Council Recommendation defines eleven common elements for describing a micro-credential. They are a useful completeness baseline, but their presence does not show that the values are accurate or the credential is recognized.

Learner and origin

Identification of the learner
Country or region of the issuer
Awarding body or bodies
Date of issuing

Resolve identifiers without replacing them with display labels. Compare the sealed organization evidence with the awarding and, where distinct, sealing roles.

Learning achievement

Title of the micro-credential
Learning outcomes
Notional workload, expressed in ECTS where possible
Learning-experience level and cycle where applicable

Preserve language maps, units, framework URIs, and the relationship between the achieved claim and its specification. Do not invent an EQF level where none applies.

Assessment and assurance

Type of assessment
Form of participation in the learning activity
Type of quality assurance underpinning the credential

Validate structure and controlled concepts, then let the relying party decide whether the stated assessment and quality assurance are sufficient for its purpose.

Optional does not mean disposable

The Recommendation also identifies optional information such as prerequisites, supervision and identity verification during assessment, grade, stackability, and further information. Preserve it when supplied and valid; configure purpose-specific requirements instead of making every optional property globally mandatory.

Recognition stays outside

The Recommendation is explicit that use of the standard elements does not itself imply official validation or recognition. Return the technical and semantic evidence; route regulated-profession, admission, credit-transfer, and qualification-equivalence decisions to the competent process.

Make the API result reviewable

The response below is a Yarify-recommended relying-party contract, not an ELM schema or Commission API response. It shows how to keep parsed claims, cryptographic evidence, live checks, warnings, and the caller's decision separate.

{
  "requestId": "vrf_01K4...",
  "checkedAt": "2026-09-04T15:22:31Z",
  "input": {
    "kind": "edc-jsonld",
    "sha256": "3bd6...",
    "source": "holder-share-link"
  },
  "profile": {
    "model": "ELM",
    "version": "3.x-pinned",
    "applicationProfile": "edc-generic",
    "status": "pass",
    "violations": []
  },
  "checks": {
    "format":        { "status": "pass" },
    "seal":          { "status": "pass", "signer": "Example University" },
    "revocation":    { "status": "indeterminate", "reason": "source-timeout" },
    "validity":      { "status": "pass" },
    "owner":         { "status": "skipped", "reason": "no-holder-proof" },
    "accreditation": { "status": "not_applicable" }
  },
  "claims": {
    "title": "Applied Data Stewardship",
    "learningOutcomes": 4,
    "workload": { "value": 2, "unit": "ECTS" }
  },
  "verificationResult": "partially_verified",
  "policyDecision": {
    "policy": "employer-screening-v4",
    "outcome": "manual_review",
    "reasons": ["revocation-indeterminate", "owner-not-checked"]
  }
}

Control the intake

Accept bounded original files, holder-authorized share links, or authenticated wallet integrations. Restrict content types and sizes. For remote links, allowlist schemes and hosts, limit redirects and response size, and block private-network access.

Pin resolution

Resolve only approved JSON-LD contexts, application profiles, controlled lists, and trust sources. Version and cache them deliberately. Do not let untrusted credential data trigger arbitrary server-side fetches.

Minimize the output

Return only claims the named relying-party purpose needs. Redact logs, isolate tenants, encrypt artifacts, authorize evidence access, and make raw-credential retention shorter than the decision record where possible.

Design for dependency failure

Verification can depend on trust, certificate-status, revocation, controlled-list, wallet, and accreditation services. Set individual timeouts, bounded retries, circuit breakers, and freshness limits. Preserve the last known result without presenting it as current.

Inventory those components against the official EDC interoperability resources.

Keep artifacts immutable

Hash and retain the exact input when retention is justified. Any normalized view, extracted claims, converted legacy credential, or display PDF is a derivative linked to that input. Reissuing or correcting a credential belongs to the awarding workflow, not the verifier.

Version the model, profile, vocabularies, and verifier

ELM v3 is the Commission's long-term-supported model. Official QDR guidance also records a v3.3 namespace transition for current LOQ and accreditation datasets. That specific QDR change should not be generalized to every credential, but it demonstrates why “supports ELM v3” is not a sufficient compatibility contract. See the version guidance and ELM browser.

Maintain a compatibility registry

Model: Accepted ELM ontology versions, namespaces, JSON-LD contexts, and deprecation dates
Profile: Credential flavours and constraint versions, including generic, accredited, mandate, and explicitly supported extensions
Vocabulary: Controlled-list URI, retrieval source, snapshot or freshness time, fallback behavior, and unknown-code policy
Trust: Seal formats, algorithms, certificate validation policy, trust sources, status protocols, and evidence retention
Implementation: Verifier build, parser and validator versions, feature flags, known limitations, and rollback path

Test both eras deliberately

The Commission's open-source repository distinguishes JSON-LD examples for ELM v3 from XML examples for ELM v2 and documents a conversion component. Use golden files for supported variants and negative fixtures for malformed contexts, invalid seals, unknown vocabularies, expired credentials, unavailable status sources, ambiguous owners, and unmatched accreditations.

Track upstream releases through the official EDC repository. The Commission consolidated EDC, ELM Support, diagrams, mappings, and examples on its code platform in March 2026, as described in the repository announcement.

Prove one relying-party decision end to end

Start with one actual workflow: an LMS completion, university admission, employer screen, professional-development record, or recognition queue. The pilot succeeds when a reviewer can trace the original credential to each check and the resulting decision.

Define the decision
Name the relying party, purpose, credential types, jurisdictions, volumes, latency, reviewer, consequences, and what verification can and cannot decide.
Inventory formats and sources
Collect representative ELM v3 JSON-LD, legacy XML, share links, wallet flows, PDFs, custom extensions, profile declarations, and expected failure cases.
Map claims and policy
Map source systems to ELM concepts and the micro-credential elements. Define required checks, accepted issuers, accreditation conditions, owner assurance, and manual-review rules.
Integrate trust services
Choose Commission-hosted or deployed EDC components, electronic-seal validation, status and accreditation sources, authentication, network boundaries, and fallback behavior.
Apply privacy controls
Document controller and processor roles, lawful basis, notices, GDPR data minimization, field-level return policy, access, retention, deletion, audit, and incident handling.
Exercise and release
Run golden and adversarial credentials, dependency outages, version changes, tenant isolation, replay, load, accessibility, operational support, rollback, and evidence review before production.

Acceptance evidence

Approve a matrix of inputs, expected per-check outcomes, extracted claims, policy decisions, latency, dependency conditions, retained evidence, and human-readable explanations. A demo with one valid credential is not an interoperability test.

Valid, expired, not-yet-valid, and revoked credentials

Intact, broken, unknown, and unavailable seal evidence

Generic, accredited, mandate, extension, and unsupported profiles

Matching, ambiguous, missing, and privacy-minimized owner evidence

Current, missing, expired, out-of-scope, and conflicting accreditation

Legacy conversion, context failure, controlled-list drift, and dependency timeout

For a credential service that crosses hosting regions or vendors, connect the data-flow analysis to our cross-border data routing guide.

For learner and reviewer interfaces, include upload, status, explanation, keyboard, and assistive-technology paths in an accessibility audit.

Questions a verifier must answer precisely

Product copy often compresses model conformance, authenticity, accreditation, identity, and recognition into “verified.” These answers keep the boundaries visible.

Is the European Learning Model a digital badge format?

Not by itself. ELM is a multilingual ontology and set of application profiles for representing learning-related data. European Digital Credentials for Learning use an ELM credential application profile and add a verifiable, electronically sealed credential envelope. A badge image, certificate PDF, ELM-shaped JSON object, and sealed EDC are therefore not interchangeable trust artifacts.

Does ELM conformance mean that a credential is verified?

No. Semantic conformance shows that data meets the selected ontology and application-profile constraints. Verification separately examines the original credential's format, seal, validity, revocation, owner, and—where relevant—accreditation. Even a technically verified credential does not automatically establish academic recognition, professional eligibility, equivalence, or fitness for a hiring decision.

Can an API verify a screenshot or exported PDF of a credential?

It can inspect the file and any embedded link or QR code, but it should not treat pixels or an ordinary PDF snapshot as the original verifiable credential. Europass recommends using the online credential because its checks run against the current credential state. Resolve a holder-authorized share link or obtain the original EDC, preserve provenance, and state clearly when only a non-verifiable representation was supplied.

What should an EDC verification API return?

Return independent, timestamped results for input integrity, format and profile, electronic seal, certificate status, credential validity, revocation, owner, and accreditation. Include the ELM and application-profile versions, issuer and subject identifiers needed by the caller, warnings, skipped or unavailable checks, evidence references, verifier version, and a separate policy decision. Do not collapse partial or indeterminate evidence into a single true/false badge.

Are the EU micro-credential standard elements legally mandatory?

The 2022 instrument is a Council Recommendation, so its common definition, eleven standard descriptive elements, and design principles are non-binding recommendations. They may still be adopted through national, sectoral, institutional, funding, procurement, or quality-assurance rules. The Recommendation also says using the standard elements does not itself imply official validation or recognition.

Does every European Digital Credential need accreditation?

No. EDCs can represent formal qualifications, micro-credentials, participation, assessments, and other learning records. Accreditation matters where an issuer or qualification must be authorized under the applicable system. The API must distinguish not applicable, not checked, no matching accreditation, expired accreditation, and confirmed accreditation instead of treating the absence of an accreditation result as a broken seal.

Should a new integration accept legacy ELM v2 XML?

Only through an explicit compatibility path. The Commission repository separates ELM v3 JSON-LD examples from ELM v2 XML examples and describes a conversion component. Preserve the original artifact and its verification result, identify the source version, validate before conversion, and treat the converted object as a derivative. Never imply that transforming legacy XML preserves or recreates the original seal.

Which electronic seal is required to issue an EDC?

Current Europass issuer material describes an eIDAS-compliant advanced or qualified electronic seal, while deployment documentation for the Community Edition describes a qualified electronic seal. Confirm the exact issuer service, certificate profile, trust-service provider, national context, and operational signing path before implementation. A verifier should report the certificate and validation evidence it actually observed rather than infer the seal level from branding.

Can a verification result be cached permanently?

No. Format and signature-integrity evidence may be stable for immutable bytes, but certificate, revocation, credential-validity, share-link, and accreditation states can change. Store the check time, source, evidence, and expiry; use bounded caching per check; and reverify before a consequential decision. An old PDF or green check is a historical snapshot, not a permanent status guarantee.

How should learner data be handled during verification?

Treat credential content and verification logs as personal data where they identify a learner. Establish controller and processor roles, purpose and lawful basis, minimize returned claims, avoid logging full credentials, restrict staff and tenant access, encrypt transport and storage, define deletion and incident procedures, and make retention configurable. Hashes and credential IDs can also remain personal data when linkable to a person.

Primary sources and status

Reviewed 4 September 2026. The Europass Decision, eIDAS, and GDPR are binding EU law, with obligations depending on the actor and processing context. The 2022 Council Recommendation on micro-credentials is non-binding. ELM and EDC application profiles, vocabularies, tools, and code are interoperability resources; they do not by themselves grant recognition, accreditation, or legal compliance. Yarify's API statuses, security controls, evidence model, caching rules, and pilot criteria are engineering recommendations—not legal advice or an official Europass service.