EAASD-JWT VC

Attestation Rulebook for attestations of type Micro-credential

Category: non-qualified EAA

[Based on the WE BUILD Attestation Rulebook Template and the WE BUILD BU5 Micro-credentials Attestation Design.]

• Author(s):
  • Stefan Liström, Sunet
  • Johan Peterson, Linköping University
  • Per von Bahr, Sunet
• Previous Authors
  • N/A

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues, or contact Work Package 4 in WE BUILD.

1 Introduction

1.1 Document scope and purpose

This Rulebook defines the Micro-credential Attestation for use in the European Digital Identity Wallet ecosystem.

The Micro-credential Attestation expresses the real-world fact that a natural person has successfully completed a small, coherent volume of formally assessed learning, delivered under the quality assurance of an educational organisation, and has thereby acquired specific learning outcomes. It follows the definition set out in the Council Recommendation of 16 June 2022 on a European approach to micro-credentials for lifelong learning and employability (2022/C 243/02): a portable, learner-owned record of assessed learning outcomes from a small volume of study, which can be aligned to a curriculum, carries a notional workload, and is issued under institutional quality assurance.

The attestation is intended to be issued by an authentic source acting as a formal education provider, such as a higher education institution (HEI) or vocational education and training (VET) provider, or by an authorised academic identity provider acting on that provider's behalf. The Holder is the natural person who completed the assessed learning. Relying Parties are expected to include universities and other HEIs evaluating admission, credit recognition, or advanced standing; employers assessing skills for recruitment or onboarding; and other organisations that need to rely on verified evidence of formally taught knowledge, skills, and competences.

In practical terms, the attestation enables a learner to present proof of one or more completed micro-credentials through an EUDI Wallet, for example to demonstrate fulfilment of entry requirements or eligibility for recognition of credits when applying to a course or programme in another country. This supports cross-border and domestic academic mobility, provided that the relying party can verify the issuer, credential signature, validity, status where applicable, and the disclosed attributes needed for its decision.

The attestation supports use cases including university admission and enrolment, recognition of prior learning and credit transfer, professional onboarding, and other formally taught knowledge-dependent procedures, in both domestic and cross-border contexts.

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.

In addition, the following domain-specific terms are used:

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 designed to align with the EUDI Wallet architectural approach for Electronic Attestations of Attributes and with the Attestation Rulebook structure defined in the ARF.

The Rulebook supports the following compliance objectives:

• it defines the attestation purpose and scope, aligned with the Council Recommendation of 16 June 2022 on a European approach to micro-credentials for lifelong learning and employability (2022/C 243/02);
• it defines mandatory, optional, and conditional attributes in an encoding-independent manner, reflecting the standard elements for describing micro-credentials set out in that Recommendation, as further specified by the European Learning Model (ELM) and the European Digital Credentials for Learning (EDC) application profile;
• it defines a legal category indication through attestation_legal_category;
• it defines an SD-JWT VC vct value for the attestation type;
• it defines issuer, awarding body, validity, and status metadata needed for verification, including a clear distinction between the organisation that seals/issues the credential and the organisation that awarded the underlying learning achievement;
• it defines code lists and integrity rules required for consistent interpretation;
• it defines how trust anchors can be obtained and used;
• it defines revocation expectations appropriate to a non-lapsing learning achievement, distinguishing technical credential validity from the continued truth of the achievement;
• it supports selective disclosure and data minimisation.

This Rulebook does not define a qualified EAA or public-sector EAA profile. It also does not define ISO/IEC 18013-5 mdoc or W3C VCDM encodings in this version, although the ELM/EDC JSON-LD-based representation is noted in Section 3.3 as a potential future basis for a W3C VCDM encoding.

This Rulebook does not define assurance or quality levels for the Micro-credential Attestation. Where a future version of this Rulebook introduces such levels, Chapters 3 and 4 SHALL be updated accordingly.

This Rulebook does not define transactional or payment-related data. Where a Micro-credential Attestation is used in a transaction involving payment, such requirements SHALL be defined in a separate payment attestation, payment profile, or transaction-specific rulebook.

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

This chapter defines the attributes and metadata that a Micro-credential Attestation may contain. The attributes are defined in an encoding-independent manner. Each attribute is classified as mandatory, optional, or conditional.

The Micro-credential Attestation records a completed, formally assessed learning achievement. Unlike affiliation-based attestations, the underlying fact it attests does not lapse over time; any validity period defined in this Rulebook concerns the technical validity of the credential instance, not the continued truth of the achievement. The attribute set reflects the standard elements for describing micro-credentials set out in the Council Recommendation of 16 June 2022 (2022/C 243/02), as further specified by the European Learning Model (ELM) and the European Digital Credentials for Learning (EDC) application profile, and supports data minimisation by allowing a Holder to disclose only the attributes required for a specific transaction.

3.1 Introduction

The Micro-credential Attestation is defined as a non-qualified Electronic Attestation of Attributes unless a future version of this Rulebook explicitly defines a qualified or public-sector legal category.

The attribute attestation_legal_category SHALL be included and SHALL have the value non-qualified-EAA.

The attestation model consists of the following logical groups:

• credential identification attributes;
• issuer and awarding body attributes;
• learner identity attributes for holder matching;
• learning achievement attributes (outcomes, level, workload, assessment, participation);
• classification and taxonomy references;
• quality assurance and accreditation attributes;
• credential metadata.

Note that, consistent with the European Learning Model, the organisation that seals/issues the credential (see issuerCountry) and the organisation that awarded the underlying learning achievement (see awardingBody) may or may not be the same organisation; one organisation may seal credentials on behalf of another.

The attestation is issued as a Verifiable Credential compatible with the EUDI Wallet using SD-JWT VC. The model aligns with the following issuer metadata parameters:

• scope: MicroCredential;
• format: vc+sd-jwt;
• vct: https://webuildconsortium.eu/credentials/microcredential/1.0;
• claims: the claims defined in this Rulebook;
• proof_types_supported: issuer-defined, including jwt where supported;
• cryptographic_binding_methods_supported: issuer-defined, for example jwk or cose_key.

Note on schema artefacts. Section 3.1 of the generic template requires a machine-readable schema artefact for every format marked supported in chapter 5, versioned and immutably addressable. No such artefact exists yet for this attestation under data-schemas/. Adding one is follow-up work, tracked as a known gap rather than resolved here.

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 states in section 3.1 that the attribute attestation_legal_category SHALL be included with the value non-qualified-EAA.

Open point for the quality assurance group. Section 4.1 of the generic template states that attestation_legal_category is superseded by the category attribute of [ETSI TS 119 472-1] and SHALL NOT be used, and that a non-qualified EAA carries category with the value eaa:eu:non-qualified. Unlike PID, a migration target does therefore exist for this attestation. The attribute has been left as the authors wrote it, because renaming it would also change the normative claim tables and the worked examples in chapter 5, which is an authoring decision rather than a restructuring one. Note also that EW-DM-12-029 (legacy ARB_25) of ARF v3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF currently disagree.

4.2 Optional metadata

4.3 Conditional metadata

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

The Micro-credential Attestation SHALL be issued as an SD-JWT VC.

The Verifiable Credential Type (vct) for this attestation type is:

https://webuildconsortium.eu/credentials/microcredential/1.0

The credential claims defined in this section SHALL follow SD-JWT VC and HAIP conventions where applicable. Claim names are either IANA-registered JWT claims, public or reusable names, or private names specific to this attestation type.

For all claims, this Rulebook specifies whether an Attestation Provider MUST, MAY, or MUST NOT make the claim selectively disclosable.

5.1.1 IANA-registered and standard JWT / SD-JWT VC claims

5.1.2 Public or reusable claims

5.1.3 Private claims specific to the Micro-credential Attestation

5.1.4 Example minumum JWT claim set

{
  "iss": "https://issuer.example-university.edu",
  "iat": 1781740800,
  "vct": "https://webuildconsortium.eu/credentials/microcredential/1.0",
  "attestation_legal_category": "non-qualified-EAA",
  "identifier": "MC-2026-0007421",
  "title": "Introduction to Applied Data Ethics",
  "givenName": "Elena",
  "familyName": "Kowalska",
  "issuerCountry": "http://publications.europa.eu/resource/authority/country/SWE",
  "awardingBody": {
    "legalName": "Linköping University",
    "legalIdentifier": "999852236"
  },
  "issuanceDate": "2026-06-15",
  "learningOutcomes": [
    {
      "title": "The title of the learning outcome 1", 
      "description": "The actual learning outcome 1"
    },
    {
      "title": "The title of the learning outcome 2", 
      "description": "The actual learning outcome 2"
    }
  ],
  "ECTS": 3.0,
  "typeOfAssessment": [
    "http://data.europa.eu/snb/assessment/6a4db9f11d"
  ],
  "formOfParticipation": "http://data.europa.eu/snb/learning-assessment/920fbb3cbe",
  "qualityAssurance": "institutional-accreditation",
  "trust_anchor": "https://trust.example.eu/education/institutions/example-university",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

5.1.5 Example JWT claim set (not implemented yet)

{
  "iss": "https://issuer.example-university.edu",
  "iat": 1781740800,
  "nbf": 1781740800,
  "jti": "urn:uuid:9a3f6b2e-1c44-4b8a-9e21-6f0a2d7c5b31",
  "vct": "https://webuildconsortium.eu/credentials/microcredential/1.0",
  "attestation_legal_category": "non-qualified-EAA",
  "identifier": "MC-2026-0007421",
  "title": "Introduction to Applied Data Ethics",
  "givenName": "Elena",
  "familyName": "Kowalska",
  "issuerCountry": "http://publications.europa.eu/resource/authority/country/SWE",
  "awardingBody": {
    "legalName": "Linköping University",
    "legalIdentifier": "999852236"
  },
  "awardingBodyHomepage": "https://liu.se",
  "issuanceDate": "2026-06-15",
  "level": "EQF-6",
  "learningOutcomes": [
    {
      "title": "The title of the learning outcome 1", 
      "description": "The actual learning outcome 1"
    },
    {
      "title": "The title of the learning outcome 2", 
      "description": "The actual learning outcome 2"
    }
  ],
  "fieldOfEducation": "0613",
  "escoReference": [
    "http://data.europa.eu/esco/skill/abc12345"
  ],
  "ECTS": 3.0,
  "typeOfAssessment": [
    "http://data.europa.eu/snb/assessment/6a4db9f11d"
  ],
  "formOfParticipation": "http://data.europa.eu/snb/learning-assessment/920fbb3cbe",
  "grade": "Pass",
  "gradingScheme": "Pass/Fail",
  "qualityAssurance": "institutional-accreditation",
  "accreditation": {
    "title": "Institutional Accreditation 2024",
    "type": "institutional-accreditation",
    "accreditingAgent": "Swedish Higher Education Authority",
    "decision": "approved",
    "decisionDate": "2024-01-15",
    "reviewDate": "2029-01-15"
  },
  "stackable": true,
  "partOfQualification": "BSc Data Science, Linköping University",
  "trust_anchor": "https://trust.example.eu/education/institutions/example-university",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

5.1.6 Example issued SD-JWT

The following is a non-normative placeholder example. A production SD-JWT SHALL be generated by the issuer using the applicable signing algorithm, disclosure construction, holder binding, and SD-JWT VC rules.

<issuer-signed-sd-jwt>~<disclosure-1>~<disclosure-2>~<disclosure-n>~<holder-binding-jwt>

5.1.7 Example human-readable disclosed payload

A university admissions office requesting evidence of a completed prerequisite micro-credential for course entry may receive a presentation disclosing the following claims:

{
  "vct": "https://webuildconsortium.eu/credentials/microcredential/1.0",
  "identifier": "MC-2026-0007421",
  "title": "Introduction to Applied Data Ethics",
  "givenName": "Elena",
  "familyName": "Kowalska",
  "issuerCountry": "http://publications.europa.eu/resource/authority/country/SWE",
  "awardingBody": {
    "legalName": "Linköping University",
    "legalIdentifier": "999852236"
  },
  "learningOutcomes": [
    {
      "title": "The title of the learning outcome 1", 
      "description": "The actual learning outcome 1"
    },
    {
      "title": "The title of the learning outcome 2", 
      "description": "The actual learning outcome 2"
    }
  ],
  "ECTS": 3.0,
  "typeOfAssessment": [
    "http://data.europa.eu/snb/assessment/6a4db9f11d"
  ]
}

A verifier that only needs to confirm completion of the micro-credential SHOULD request the minimum claims necessary for that decision and SHOULD NOT request dateOfBirth, mail, nationalID, placeOfBirth, citizenshipCountry, or registeredAddress unless required for the transaction, for example strong holder matching.

The issuer identity, credential type, expiry time, signature, holder binding proof, and trust anchor information are not treated as selectively disclosable attributes and SHALL remain available to the verifier for technical validation.

5.2 ISO/IEC 18013-5-compliant encoding

This version of the Rulebook does not define an ISO/IEC 18013-5 mdoc encoding for the Micro-credential Attestation.

The Micro-credential Attestation defined in this Rulebook is specified for SD-JWT VC-based issuance and presentation. If a future version of this Rulebook defines an ISO/IEC 18013-5-compliant mdoc representation, that version SHALL define a unique document type, namespaces, attribute identifiers, CBOR encoding rules, and illustrative mdoc examples.

5.3 W3C Verifiable Credentials Data Model-based encoding

This version of the Rulebook does not define a W3C Verifiable Credentials Data Model encoding for the Micro-credential Attestation.

If a future version defines a W3C VCDM representation, that version SHALL define the credential context, type, credential subject structure, proof type, selective disclosure mechanism, and presentation requirements. Note that the European Learning Model's own JSON-LD-based encoding (as used by the European Digital Credentials for Learning infrastructure) is a W3C VCDM-compatible representation and MAY inform such a future encoding, subject to alignment with the EUDI Wallet's SD-JWT VC-based interoperability requirements.

6 Protocols

6.1 Issuance

The Micro-credential Attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI], with the issuer metadata parameters recorded in section 3.1, including scope MicroCredential and format vc+sd-jwt.

6.2 Presentation

The Micro-credential Attestation is presented using OpenID for Verifiable Presentations [OpenID4VP]. Only remote presentation is in scope, consistent with the formats recorded in chapter 5.

7 Issuance

7.1 Binding

Holder binding is expressed through the cnf claim recorded in section 4.1, where it is used. Where the attestation must be presented together with PID or another identity attestation, cryptographically_bound_to is used as recorded in section 4.3.

7.2 Issuance Policy

The issuer SHOULD support revocation or suspension as described in chapter 8.

7.3 Lifecycle management

• The awarding body or an authorised academic identity provider issues the attestation after the underlying learning achievement has been formally assessed and completed.
• The exp claim, where present, reflects the technical validity of the credential instance rather than the continued truth of the learning achievement, as recorded in chapter 8.
• Where a corrected or superseding credential is issued, the original is revoked and the relationship between the two is recorded as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

The Micro-credential Attestation records a completed, formally assessed learning achievement. Unlike affiliation-based attestations, the underlying fact it attests — that the learner achieved the stated learning outcomes — does not lapse over time and does not need to be periodically re-established. Consequently, revocation of a Micro-credential Attestation is not a mechanism for expressing that the achievement is "no longer valid" in a temporal sense, but a mechanism for correcting the record where the original issuance was defective or the credential instance itself needs to be withdrawn.

The credential expiration time (exp), where present, SHALL be understood as reflecting only the technical validity of the credential instance, for example to encourage periodic re-issuance onto current cryptographic material, and SHALL NOT be interpreted by a Relying Party as an indication that the underlying learning achievement itself has expired.

The issuer SHOULD support revocation or suspension of a Micro-credential Attestation where any of the following applies:

• the credential was issued in error, for example to the wrong natural person or with incorrect attribute values;
• the underlying assessment is subsequently found to have been invalid, for example due to an academic integrity finding such as plagiarism or assessment fraud;
• the awarding body's authorisation or accreditation to award the underlying qualification is withdrawn or successfully challenged with retroactive effect;
• the credential is reported lost, compromised, or fraudulently obtained;
• the awarding body issues a corrected or superseding version of the credential, for example following a grade appeal or administrative correction.

Revocation MAY be handled by one or more of the following mechanisms:

• an attestation status list mechanism, where supported (see [Topic 7] of Annex 2 of the ARF);
• an attestation revocation list mechanism, where supported;
• backend verification by the awarding body or authorised academic identity provider;
• publication of a corrected or superseding credential together with revocation of the original.

If a status or revocation mechanism is included in the credential, the Relying Party SHALL check the status before accepting the attestation, unless offline operating rules explicitly allow deferred status checking.

Because the Micro-credential Attestation is not time-bound in the same way as an affiliation-based attestation, the issuer SHOULD retain the ability to check and communicate status for as long as the credential can reasonably be expected to be presented, which may extend well beyond a single academic year or enrolment period.

Where a Micro-credential Attestation is revoked and superseded by a corrected version, the issuer SHOULD ensure that the identifier of the superseding credential allows a Relying Party, where necessary and with the Holder's cooperation, to establish the relationship to the revoked credential.

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 remaining lifetime of the attestation is below 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 attestation usage chapter of the previous version of this Rulebook:

The Micro-credential Attestation is intended for verifying that a natural person has completed a specific, formally assessed learning achievement and the associated learning outcomes.

Typical usage scenarios include:

• presentation by a learner to a university or other higher education institution to demonstrate fulfilment of entry requirements or eligibility for recognition of credits when applying for a course or programme;
• presentation for professional onboarding or recruitment where formally taught knowledge, skills, or competences are relevant to the role;
• presentation for recognition of prior learning or credit transfer between formal education providers;
• presentation in both domestic and cross-border contexts, subject to semantic interpretation, policy alignment, and recognition practices that may vary across sectors and jurisdictions.

Usage covers both:

• online verification by a service provider using remote presentation protocols;
• offline or low-connectivity verification where the verifier can validate the credential signature, issuer, validity period, status where available, and disclosed attributes without relying on a real-time issuer backend.

A Relying Party receiving the attestation SHALL verify:

• the issuer signature;
• the SD-JWT VC type (vct);
• the issuer authorisation to issue Micro-credential Attestations;
• the credential validity period, where present;
• the credential status, where a status mechanism is present;
• holder binding, where used;
• the integrity rules defined in Section 4.5;
• that the disclosed attributes are sufficient for the relying-party decision.

The Relying Party SHALL distinguish between verification of the attestation and evaluation of whether the attested learning outcomes are sufficient for its purpose. Successful cryptographic or technical verification alone SHALL NOT be treated as sufficient proof that the attested learning outcomes meet the Relying Party's acceptance criteria; the Relying Party SHALL evaluate the attested skill claim against its own defined criteria relevant to the intended use context, for example admission requirements or credit recognition rules.

The Relying Party SHOULD be able to interpret:

• any assurance or quality level associated with the attestation, where such levels are defined by a future version of this Rulebook;
• recognised taxonomy or classification references, such as ESCO or ISCED-F references, where included in the attestation.

The Relying Party SHOULD request and verify a PID or another accepted identity credential where the transaction requires strong identity matching between the Holder and the attestation subject. For low-risk checks, the Relying Party MAY rely on the Micro-credential Attestation alone, provided that the issuer, signature, validity, status, and holder binding checks are successful and this is consistent with the relying party's policy.

The Relying Party SHALL apply data minimisation and SHALL request only the attributes required for the transaction. For example, a credit-recognition decision may only need title, awardingBody, level, learningOutcomes, and notionalWorkload, while an identity-sensitive enrolment process may additionally require givenName, familyName, and strong holder-binding verification via a PID.

The Relying Party SHOULD be able to evaluate the Micro-credential Attestation together with other supporting attestations where combined evidence is required, for example where several micro-credentials are presented to demonstrate cumulative fulfilment of entry requirements.

The Relying Party SHOULD define fallback handling for cases in which the attestation cannot be accepted, including rejection, request for additional evidence, deferred decision, or referral to an alternative process.

The attestation SHOULD be device-bound through holder binding where supported by the EUDI Wallet and the applicable SD-JWT VC profile. The attestation MAY be cryptographically bound to a PID or another accepted identity attestation where strong identity matching is required. Where this binding is used, the metadata attribute cryptographically_bound_to SHOULD contain:

urn:eudi:pid:1

No payment-specific transactional data is defined by this Rulebook. If the Micro-credential Attestation is used as part of a transaction that also involves payment, for example a paid enrolment or examination fee, payment-related requirements SHALL be defined in a separate payment attestation, payment profile, or transaction-specific rulebook; see [Topic 20] of Annex 2 of the ARF.

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is not in scope in this version, consistent with chapter 5, which records no mdoc encoding.

9.3 Transactional data

This Rulebook does not define transactional or payment-related data. Where a Micro-credential Attestation is used in a transaction involving payment, such requirements are out of scope of this version.

10 Trust Framework

Non-qualified EAA

The trust anchor is not obtained from a Trusted List of qualified trust service providers. A Relying Party obtains it as described in the deployment profile below, and verifies that the Provider is authorised to issue this attestation type by the same means.

A Wallet Unit MAY verify Provider authorisation using the mechanism described in ISSU_34 of Topic 10 of Annex 2 of the ARF.

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.

Coherence check: the attribute named here is trust_anchor, declared in section 4.2.

Deployment profile

A Relying Party SHALL verify that the issuer of the Micro-credential Attestation is authorised to issue this attestation type.

For non-qualified EAA deployments, the Relying Party SHOULD obtain trust anchor information through one or more of the following mechanisms:

• a machine-readable trust list or trust registry used by the relevant education or EUDI Wallet ecosystem, such as the general trust lists supplied by the WE BUILD project;
• an issuer metadata endpoint published by the formal education provider or authorised academic identity provider;
• a trust framework entry managed by the WE BUILD ecosystem or by another authorised governance body;
• a pilot trust list used for controlled interoperability testing;
• a sectoral trust framework used by higher education, VET, or research and education identity providers, where applicable, such as trust registries aligned with the European Digital Credentials for Learning infrastructure.

Where the metadata attribute trust_anchor is present, it SHOULD identify the location or registry entry from which the Relying Party can obtain the issuer trust anchor or issuer authorisation information.

The Relying Party SHALL use the trust anchor to verify that:

• the issuer signing key or certificate chains to a trusted authority or registered trust anchor;
• the issuer is authorised to issue the https://webuildconsortium.eu/credentials/microcredential/1.0 attestation type;
• the issuer metadata or trust framework entry has not expired or been revoked;
• the issuer identity in the credential is consistent with the issuer identity in the trust framework;
• the issuer is a formal education provider, or an authorised academic identity provider acting on behalf of one, for the relevant type of learning outcome.

Because the organisation that seals/issues the credential (issuerCountry) may differ from the organisation that awarded the underlying learning achievement (awardingBody), the Relying Party SHALL verify issuer trust based on the sealing organisation's trust anchor, and MAY additionally seek confirmation, for example through the accreditation information in Section 3.3 or through the trust framework entry, that the awarding body was itself entitled to award the micro-credential at the time of issuance.

Wallet Units MAY also use the same trust framework information during issuance to determine whether the provider is authorised to issue this attestation type.

11 References