Nexiel Credentials lets a vetted university, technological university, or other accredited body issue verifiable academic credentials (enrolment proofs, module completions, degree awards) directly into a student's EU Digital Identity (EUDI) wallet. This page explains the shape of the credential itself, the vetting gate an institution passes through first, how a student receives one, and what kind of trust it carries. For the request/response walkthrough, see the Credentials API quickstart. New to EUDI wallets generally? Read what an EU Digital Identity Wallet is first.
Every credential Nexiel issues is an SD-JWT VC (Selective Disclosure JWT Verifiable Credential): a signed JSON document with some of its claims individually hidable, so a student can later show a verifier only the claims that verifier needs. A degree award credential can disclose the degree title and award date without disclosing anything else about the student, and a verifier who only asked for enrolment status never sees a completed degree at all.
Three credential types exist today: ENROLMENT, MODULE_COMPLETION, and DEGREE_AWARD. Each has one fixed vct(credential type identifier) shared across every Nexiel-vetted institution, so a verifier's query accepts a degree credential from any vetted university with a single rule, rather than one rule per institution. What varies per institution is the claim schema inside a template (see the quickstart), never the outward-facing type.
Each credential is bound to one specific wallet through a cnf(confirmation) claim carrying that wallet's own public key, generated on the device and never sent to Nexiel in advance. A copied credential is not a usable credential: presenting it requires signing with the private half of that same key, which only the original wallet holds. A real credential Nexiel issued in sandbox mode decodes to this shape:
{
"iss": "https://sandbox-university.nexiel-docs.example",
"vct": "urn:nexiel:credential:degree-award:v1",
"iat": 1787683632,
"cnf": {
"jwk": {
"kty": "EC",
"x": "LrH-ob9ebxjB2ml6-71PbFGeiA_ewxlYxIlh98WaOic",
"y": "6VRGs39V6tyq43qfidOwNOJZRq2RSdZdAXxgJONT0ms",
"crv": "P-256"
}
},
"studentFullName": "Sandbox Docs Graduate",
"_sd": [
"BF8NBJRheMduxHeQ7w2rFzj_plnk_zNCqvwumlUt81k",
"UHFeWkIFu4xi7CBj4F691O3MxKbun_3Z47FcShOeuyI"
],
"_sd_alg": "sha-256"
}issis the issuing institution's own verified domain, never a shared Nexiel identity. Each institution signs with its own key, so a verifier resolving trust is resolving trust in that institution specifically, not in Nexiel as an intermediary. The two _sd digests correspond to the degree title and award date, delivered alongside the signed body as separate disclosures the holder chooses whether to reveal.
A legally registered institution is not automatically an accredited one, so Nexiel checks both separately before granting issuer status. An applicant goes through legal-entity registry verification, sanctions/PEP screening of the entity itself, and corroborating lookups against ROR (Research Organization Registry) and eduGAIN's federated identity membership records. It must also prove control of the domain its credentials will be signed under, and register at least two active signatories (named people the institution asserts hold real signing authority there).
None of those checks alone can confirm genuine degree-awarding authority, so every application goes to a human reviewer. There is no automatic approval path, and approval itself is refused outright if fewer than two active signatories are on record at the moment of the decision. Once approved, an institution provisions its own signing key and can start proposing credential templates.
A credential template (the claim schema for one credential type at one institution) goes through its own, separate Nexiel review before it can issue anything. See the Credentials API quickstart for that flow.
Delivery uses OpenID4VCI (OpenID for Verifiable Credential Issuance), issuer-initiated: once a credential is ready to issue, Nexiel creates a redemption offer scoped to that one student and one credential, and the institution delivers the offer as a link or QR code. The offer embeds a single-use pre-authorized code, not the credential itself.
The student's wallet resolves the offer, exchanges the pre-authorized code for a short-lived access token, then proves possession of its own private key by signing a small JWT that echoes a fresh nonce back to Nexiel. Only then does Nexiel sign and return the actual credential. Both the pre-authorized code and the access token are single-use. Redeeming the same code twice, or presenting the same access token to request a second credential, is refused rather than silently issuing a duplicate.
A Nexiel-issued credential is an EAA (Electronic Attestation of Attributes), not a QEAA (Qualified Electronic Attestation of Attributes). The distinction is a real legal one, not a marketing one. A QEAA is issued by a qualified trust service provider under formal EU supervision, and sits on an EU-wide eIDAS Trusted List that any relying party can check directly. That gives it the strongest, most portable legal standing available under eIDAS 2.0 (the EU digital identity regulation).
A non-qualified EAA, which is what every Nexiel Credentials degree, enrolment, or module completion is today, has no equivalent EU-wide trust list to sit on. Trust rests instead on what the EU's own architecture calls another legal or contractual framework, and here that framework is Nexiel's own vetting gate above: an institution only holds a signing key after passing that review, and a credential's issclaim names the institution itself, never Nexiel. A verifier is trusting the vetted institution, on the strength of Nexiel's vetting process, not trusting Nexiel as a qualified issuer by proxy.
Qualified, QTSP-backed issuance is an architectural option Nexiel's signing layer is built to support later, not something live today. Every credential issued right now is a non-qualified EAA.