EAASD-JWT VC

Attestation Rulebook for attestations of type Student ID

Category: non-qualified EAA

[Based on the WE BUILD Attestation Rulebook Template and the StudentID Attestation model.]

• Author(s):
  • Nikos Triantafyllou, UAegean
• Previous Authors
  • N/A

Feedback:

• Github, portal, email, Slack

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

Feedback: GitHub issues

1 Introduction

1.1 Document scope and purpose

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

The StudentID Attestation expresses the real-world fact that a natural person is, or was during the applicable validity period, affiliated with an educational organisation in a student capacity. It enables relying parties to verify student status and selected identity or affiliation attributes using the EUDI Wallet.

The attestation is intended to be issued by an authentic source, such as a university, higher-education institution, or authorised academic identity provider. The Holder is the natural person to whom the student status applies. Relying Parties may include campus service providers, libraries, laboratories, access-control systems, mobility services, student-discount service providers, public or private service providers accepting student status, and other authorised verifiers.

In practical terms, the attestation enables a student to present proof of student status through an EUDI Wallet using selective disclosure. It can reduce reliance on paper student cards, manual checks, or real-time backend lookups, provided that the relying party can verify the issuer, credential signature, validity period, credential status where applicable, and the disclosed attributes needed for the transaction.

The attestation supports education and student-service use cases, including online and offline verification for campus services, discounted services, access control, mobility scenarios, academic services, and other scenarios where proof of student affiliation is required.

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;
• it defines mandatory, optional, and conditional attributes in an encoding-independent manner;
• 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, validity, and status metadata needed for verification;
• it defines code lists and integrity rules required for consistent interpretation;
• it defines how trust anchors can be obtained and used;
• it defines expiry and revocation expectations;
• 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.

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.

3.1 Introduction

The StudentID 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:

• student identification attributes;
• organisation attributes;
• core identity attributes for holder matching;
• contact attributes;
• affiliation and status attributes;
• credential metadata.

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: StudentID;
• format: vc+sd-jwt;
• vct: VerifiableStudentID;
• 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.

Chapter overview and requirements

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

The StudentID Attestation is typically medium- to long-lived, for example for an academic year, and is intended for repeated presentation with selective disclosure. The attribute set is designed to support data minimisation by allowing a Holder to disclose only the student attributes required for a specific transaction.

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], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, 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.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

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

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

VerifiableStudentID

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 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 StudentID Attestation

5.1.4 Example JWT claim set

{
  "iss": "https://issuer.example-university.edu",
  "iat": 1772366400,
  "nbf": 1772366400,
  "exp": 1798761600,
  "jti": "urn:uuid:4f6a8e9a-40c2-4d21-96f8-7b85cc3f6c20",
  "vct": "VerifiableStudentID",
  "attestation_legal_category": "non-qualified-EAA",
  "identifier": "STU-2026-000123",
  "schacPersonalUniqueCode": "urn:schac:personalUniqueCode:int:esi:example.edu:123456",
  "schacPersonalUniqueID": [
    "urn:schac:personalUniqueID:gr:student:123456"
  ],
  "schacHomeOrganization": "aegean.gr",
  "firstName": "Nikos",
  "familyName": "Triantafyllou",
  "displayName": "Nikos Triantafyllou",
  "commonName": "Nikos Triantafyllou",
  "dateOfBirth": "1990-04-12",
  "mail": "ntriantafyllou@aegean.gr",
  "eduPersonPrincipalName": "ntriantafyllou@aegean.gr",
  "eduPersonPrimaryAffiliation": "student",
  "eduPersonAffiliation": [
    "student",
    "member"
  ],
  "eduPersonScopedAffiliation": [
    "student@aegean.gr"
  ],
  "eduPersonAssurance": [
    "https://refeds.org/assurance"
  ],
  "trust_anchor": "https://trust.example.eu/education/institutions/example-university",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

5.1.5 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.6 Example human-readable disclosed payload

A verifier that requests only proof of student status for a discounted service may receive a presentation disclosing the following claims:

{
  "vct": "VerifiableStudentID",
  "identifier": "STU-2026-000123",
  "schacHomeOrganization": "aegean.gr",
  "firstName": "Nikos",
  "familyName": "Triantafyllou",
  "eduPersonPrimaryAffiliation": "student",
  "eduPersonScopedAffiliation": [
    "student@aegean.gr"
  ]
}

A verifier that only needs to know whether the Holder has student status SHOULD request the minimum claims necessary for that decision and SHOULD NOT request dateOfBirth, mail, or unique identifiers unless required for the transaction.

The issuer identity, credential type, expiry time, signature, holder binding proof, and trust anchor information are not treated as selectively disclosable student 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 StudentID Attestation.

The StudentID 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 StudentID 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.

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

The StudentID Attestation is intended for verifying student status and selected student identity or affiliation attributes.

Typical usage scenarios include:

• presentation by the student for campus services such as libraries, laboratories, rooms, buildings, or academic platforms;
• presentation for student discounts or eligibility checks;
• presentation for mobility scenarios involving another educational organisation or service provider;
• 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 StudentID Attestations;
• the credential validity period;
• the credential status, where a status mechanism is present;
• holder binding, where used;
• the integrity rules defined in Section 2.9;
• that the disclosed student attributes are sufficient for the relying-party decision.

The Relying Party SHOULD request and verify PID or another accepted identity credential where the transaction requires strong identity matching. For low-risk student-status checks, the Relying Party MAY rely on the StudentID 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 discount service may only need eduPersonPrimaryAffiliation and schacHomeOrganization, while an account-linking process may require eduPersonPrincipalName or mail.

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 StudentID Attestation is used as part of a transaction that also involves payment, payment-related requirements SHALL be defined in a separate payment attestation, payment profile, or transaction-specific rulebook.

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

The StudentID Attestation is typically medium- to long-lived and intended for repeated presentation, for example during an academic year or enrolment period.

The credential expiration time (exp) SHOULD be aligned with the end of the applicable student-status validity period, such as the end of an academic year, enrolment period, mobility period, or other issuer-defined validity period.

Because student status can change before the planned expiry date, the issuer SHOULD support revocation or suspension where the attestation is valid for more than 24 hours.

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

• an attestation status list mechanism, where supported;
• an attestation revocation list mechanism, where supported;
• backend verification by the educational organisation or authorised academic identity provider;
• short validity with periodic re-issuance, where appropriate for the service model.

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.

The issuer SHOULD revoke or suspend the attestation if the student is no longer enrolled, loses the relevant student status, the credential was issued incorrectly, the credential is reported compromised, or the underlying student identifier is no longer valid for presentation.

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:

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

A Relying Party SHALL verify that the issuer of the StudentID 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;
• an issuer metadata endpoint published by the educational organisation 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 federation or sectoral trust framework used by research and education identity providers, where applicable.

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 VerifiableStudentID 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 an educational organisation or authorised academic identity provider for the relevant student population.

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

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