EAASD-JWT VC

Attestation Rulebook for attestations of type Verified Skill

Category: non-qualified EAA

[Based on the WE BUILD Attestation Rulebook Template, the WE BUILD BU5 Micro-credential Attestation Rulebook, and the WE BUILD BU5 Verified Skill EAA Design.]

• Author(s):
• Paul den Hertog
• Previous Authors
• N/A

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

Feedback:

• Github, portal, email, Slack

1 Introduction

1.1 Document scope and purpose

This Rulebook defines the Verified Skill Attestation for use in the European Digital Identity Wallet ecosystem.

The Verified Skill Attestation is a non-qualified Electronic Attestation of Attributes (EAA) that enables a natural person to demonstrate possession of one or more unregulated skills or competences. The attestation represents a structured and digitally verifiable claim that a specific skill or competence has been (self)assessed, validated, or otherwise established on the basis of defined evidence.

The attestation is intended for employment, workplace learning, non-formal learning, internal mobility, access to training, recruitment, onboarding, skills matching and other situations in which a Relying Party requires trustworthy evidence of a natural person's skills or competences.

Unlike a Micro-credential Attestation, a Verified Skill Attestation does not require the underlying achievement to be part of formal education, does not use an EQF level as its skill-proficiency measure, does not require workload to be expressed in ECTS, and does not assume quality assurance under the Standards and Guidelines for Quality Assurance in the European Higher Education Area (ESG).

Instead:

• proficiency SHALL be expressed using the Dreyfus Model of Skill Acquisition defined in this Rulebook;
• where workload is meaningful, it SHALL be expressed as study or learning load in hours;
• quality assurance SHALL be described using the quality-assurance method and quality-assurance level defined in this Rulebook;
• the attestation MAY refer to recognised external quality frameworks, certification schemes, accreditation mechanisms, audit procedures or standards, including applicable standards defined by e.g. ISO, or other applicable standardised frameworks;
• a skill SHOULD, where possible, be referenced to an ESCO skill or competence concept.

The Verified Skill Attestation does not in itself grant a legal licence, regulated professional status, protected title, formal qualification, ECTS credit(s), EQF level, or the right to practise a regulated profession.

The organisation that seals/issues the credential and the organisation or assessor responsible for establishing the skill may be the same organisation or different organisations.

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 EUDI Wallet Architecture and Reference Framework (ARF).

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 the Attestation Rulebook structure defined by the ARF.

It:

• defines a non-qualified EAA for Verified Skills;
• defines mandatory, optional and conditional attributes;
• defines a Dreyfus-based proficiency model instead of EQF;
• uses workload in hours through the ELM-compatible volumeOfLearning concept rather than ECTS;
• defines three independent QA assurance levels;
• allows documented internal QA, external assessment, audit, certification and accreditation mechanisms;
• preserves ELM interoperability where semantically appropriate;
• defines explicit extensions where ELM has no suitable property;
• supports ESCO references;
• defines an SD-JWT VC vct;
• supports selective disclosure and data minimisation;
• distinguishes issuer trust, assessment assurance and substantive skill acceptance;
• defines revocation, expiry and reassessment expectations.

This Rulebook SHALL NOT use:

• EQF or NQF level as a proxy for Dreyfus skill proficiency;
• ECTS as the unit for studyLoadHours;
• ESG as a mandatory QA basis for non-formal/workplace Verified Skills;
• the ELM educationLevel property as a substitute for Dreyfus proficiency;
• an ELM Accreditation object to represent a QA process that is not actually an accreditation.

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

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

This chapter defines the attributes and metadata that a Verified Skill Attestation may contain. Attributes are defined in an encoding-independent manner and classified as mandatory, optional or conditional.

The Verified Skill model is aligned with the European Learning Model (ELM) where a semantically appropriate ELM property exists. The ELM is capable of representing formal, non-formal and informal learning. This Rulebook therefore reuses ELM concepts where appropriate without treating education-specific properties such as EQF level or ECTS credit as suitable proxies for skill proficiency or workload.

Where ELM has no semantically correct property for a Verified Skill concept, this Rulebook defines a Verified-Skill-specific extension instead of overloading an unrelated ELM field.

3.1 Introduction

The Verified Skill Attestation is defined as a non-qualified Electronic Attestation of Attributes unless a future version explicitly defines another legal category.

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

The model consists of:

• credential identification attributes;
• issuer and assessing/awarding organisation attributes;
• Holder identity attributes for subject matching;
• skill and proficiency attributes;
• assessment and evidence attributes;
• learning/workload attributes where relevant;
• taxonomy references;
• quality-assurance attributes;
• credential metadata.

The attestation SHALL be issued as a Verifiable Credential compatible with the EUDI Wallet using SD-JWT VC.

Issuer metadata parameters:

• scope: VerifiedSkill;
• format: vc+sd-jwt;
• vct: VerifiableVerifiedSkill;
• 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.

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 retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1]. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires the legal category attribute, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

4.4 Code lists

4.4.1 Skill proficiency level

skillProficiencyLevel SHALL use the Dreyfus Model of Skill Acquisition:

The Dreyfus value describes skill proficiency, not educational level, qualification level, seniority, job grade, or EQF level. Issuers SHALL NOT algorithmically equate Dreyfus stages with EQF levels.

4.4.2 Quality-assurance level

qualityAssuranceLevel SHALL use one of the following values:

The QA level expresses the assurance context of the assessment process. It SHALL NOT be used as a proxy for the Holder's proficiency.

A higher QA level does not automatically imply that the Holder has a higher skill-proficiency level.

4.4.3 Assessment type

typeOfAssessment SHOULD reuse a suitable controlled-vocabulary value where available. Values may include:

• performance-task
• simulation
• structured-observation
• work-product-evaluation
• portfolio-assessment
• project-assessment
• assessor-judgement
• supervisor-judgement
• written-examination
• oral-examination
• other

4.4.4 Form of participation

Where formOfParticipation is used, values may include:

• workplace-based
• online
• on-site
• blended
• work-experience
• other

4.4.5 Quality-assurance method and framework

qualityAssuranceMethod and qualityFramework are intentionally extensible. The issuer SHOULD identify the method/framework precisely and SHOULD include a stable reference where available.

Examples include:

• documented internal QA procedure;
• external assessment scheme;
• professional certification scheme;
• sectoral assessment standard;
• ISO/IEC 17024 where certification of persons is applicable;
• ISO 21001 where an educational organisation's management system is relevant;
• another applicable ISO standard;
• accreditation by a competent accreditation body;
• independent audit against a documented assessment framework;
• another recognised national, sectoral, professional or organisational QA framework.

Merely naming an ISO standard SHALL NOT be interpreted as evidence of certification or accreditation. Where certification, accreditation or audit status is claimed, supporting evidence SHOULD be identifiable.

4.4.6 Legal category

attestation_legal_category SHALL be non-qualified-EAA for this version of the Rulebook.

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

The Verified Skill Attestation SHALL be issued as an SD-JWT VC.

The Verifiable Credential Type (vct) is:

VerifiableVerifiedSkill

Claims SHALL follow SD-JWT VC and HAIP conventions where applicable.

5.1.1 Standard JWT / SD-JWT VC claims

5.1.2 Public or reusable claims

5.1.3 Claims specific to the Verified Skill Attestation

5.1.4 Example JWT claim set

{
  "iss": "https://issuer.skills.example.eu",
  "iat": 1781740800,
  "jti": "urn:uuid:4a3f6b2e-1c44-4b8a-9e21-6f0a2d7c5b31",
  "vct": "VerifiableVerifiedSkill",
  "attestation_legal_category": "non-qualified-EAA",
  "identifier": "VS-2026-0007421",
  "title": "Industrial Hydrogen Compressor Operation",
  "givenName": "Elena",
  "familyName": "Kowalska",
  "issuerCountry": "NL",
  "awardingBody": "Example Hydrogen Training Centre",
  "issuanceDate": "2026-06-15",
  "skillOutcome": "Operates an industrial hydrogen compressor safely under normal operating conditions",
  "escoReference": [
    "http://data.europa.eu/esco/skill/example"
  ],
  "skillProficiencyLevel": "competent",
  "studyLoadHours": 80,
  "typeOfAssessment": "structured-observation",
  "assessmentBasis": "Observed operation during three supervised production shifts",
  "formOfParticipation": "workplace-based",
  "idVerificationMethod": "onsite-with-identity-verification",
  "qualityAssuranceLevel": "third-party-assessed",
  "qualityAssuranceMethod": {
    "type": "external-assessment-procedure",
    "name": "Independent Workplace Skills Assessment Scheme"
  },
  "assessor": {
    "name": "Example Independent Skills Assessment Foundation"
  },
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

5.1.5 Example issued SD-JWT

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

5.1.6 Example human-readable disclosed payload

A Relying Party assessing whether a candidate possesses a required skill may request:

{
  "vct": "VerifiableVerifiedSkill",
  "title": "Industrial Hydrogen Compressor Operation",
  "awardingBody": "Example Hydrogen Training Centre",
  "skillOutcome": "Operates an industrial hydrogen compressor safely under normal operating conditions",
  "skillProficiencyLevel": "competent",
  "typeOfAssessment": "structured-observation",
  "qualityAssuranceLevel": "third-party-assessed"
}

The verifier SHOULD request only the minimum claims necessary for the decision.

5.2 ISO/IEC 18013-5-compliant encoding

This version does not define an ISO/IEC 18013-5 mdoc encoding for the Verified Skill Attestation.

If a future version defines an mdoc representation, that version SHALL define a unique document type, namespaces, attribute identifiers, CBOR encoding rules and illustrative examples.

5.3 W3C Verifiable Credentials Data Model-based encoding

This version does not define a W3C VCDM encoding.

The ELM/EDC JSON-LD representation MAY inform a future W3C VCDM encoding, subject to alignment with EUDI Wallet interoperability requirements.

6 Protocols

6.1 Issuance

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI], as profiled by [HAIP].

6.2 Presentation

This attestation is presented using OpenID for Verifiable Presentations [OpenID4VP]. Only remote presentation is in scope, consistent with chapter 5, which records the mdoc encoding as out of scope.

7 Issuance

7.1 Binding

7.2 Issuance Policy

General obligations on Attestation Providers are out of scope of this Rulebook. They are specified in Topic 10 of Annex 2 of the ARF, in the applicable Implementing Regulations, and in [ETSI TS 119 471]. This Rulebook states only obligations specific to this attestation type.

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

A Verified Skill Attestation represents an assessed skill at a given point or period in time. Unlike a formal educational achievement that necessarily remains historically true once awarded, the practical relevance of some skills may diminish due to technological change, non-use, safety requirements, changing procedures, or sector-specific revalidation requirements.

Therefore, this Rulebook distinguishes:

• revocation, withdrawal because the credential should no longer be relied on as issued;
• expiry, technical end of validity of the credential instance;
• review/reassessment date, a domain-specific signal that the skill should be reassessed.

The issuer SHOULD support revocation or suspension where:

• the credential was issued in error;
• the underlying assessment is found invalid or fraudulent;
• the credential was fraudulently obtained;
• the credential is superseded by a corrected version;
• the assessment or QA evidence on which issuance relied is invalidated with relevant retroactive effect.

The issuer MAY include a reviewDate where skill currency matters.

A Relying Party SHALL NOT interpret absence of a review date as evidence that a skill can never become outdated. Skill currency is a relying-party/domain decision unless a governing framework states otherwise.

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

The Verified Skill Attestation is intended to verify that a natural person possesses an identified skill or competence at a stated Dreyfus proficiency level and that the claim was established through a described assessment and QA process.

Typical scenarios include:

• recruitment and candidate screening;
• internal mobility and role assignment;
• workplace learning and skills recognition;
• access to further training;
• recognition of non-formal or informal learning;
• skills-based matching between individuals and opportunities;
• cross-border presentation of workplace or non-formal skills.

A Relying Party SHALL verify:

• issuer signature;
• SD-JWT VC type (vct);
• issuer authorisation to issue Verified Skill Attestations;
• credential validity period, where present;
• credential status, where present;
• holder binding, where used;
• integrity rules in Section 4.5;
• sufficiency of disclosed attributes.

A Relying Party SHALL distinguish:

1. technical verification of the credential;
2. assurance evaluation of how the skill was assessed and quality-assured; and
3. substantive evaluation of whether the skill and proficiency are sufficient for the Relying Party's purpose.

Successful cryptographic verification SHALL NOT by itself imply acceptance of the skill claim for a particular role or activity.

The Relying Party SHOULD be able to interpret both skillProficiencyLevel and qualityAssuranceLevel. These dimensions SHALL be evaluated independently.

The Relying Party SHOULD request PID or another accepted identity credential where strong Holder matching is required.

The Relying Party SHALL apply data minimisation.

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is not in scope, consistent with chapter 5, which records the mdoc encoding as out of scope.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

The trust anchor is obtained as described in the branch below that corresponds to the legal category under which the attestation was issued.

A Relying Party SHALL verify that the issuer is authorised to issue the VerifiableVerifiedSkill attestation type.

For non-qualified EAA deployments, trust may be established through one or more of:

• a machine-readable trust list or trust registry used by the relevant EUDI Wallet or sectoral ecosystem;
• issuer metadata;
• a WE BUILD trust-framework entry;
• a pilot trust list;
• a sectoral trust framework;
• another governance mechanism authorised for the deployment.

Issuer authorisation and assessment/QA assurance are distinct.

A valid trust anchor proving that an organisation may issue Verified Skill Attestations does not by itself prove that a particular assessment method is externally audited, accredited or certified. Conversely, QA evidence does not by itself establish EUDI issuer authorisation.

Where the assessing organisation differs from the issuer, the Relying Party MAY evaluate the assessor and QA evidence separately from the issuer trust anchor.

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.

11 References

Annex A, ELM mapping decisions for Verified Skills

This annex is informative but records the semantic mapping decisions used by this Rulebook.

Annex A.1 Important semantic distinction

The three main confidence dimensions in a Verified Skill Attestation are independent:

1. What skill is claimed?, skillOutcome, preferably linked to ESCO.
2. How proficient is the Holder?, skillProficiencyLevel using Dreyfus.
3. How much assurance exists around the assessment?, qualityAssuranceLevel plus qualityAssuranceMethod.

Implementations SHALL NOT collapse these dimensions into one score or level.