Introduction & Core Concepts

Before creating anything in Nexus, it helps to know the small vocabulary the rest of this guide relies on. Everything in the UI is a direct reflection of these concepts.

Wallets (Identities)

In Nexus, an Identity and a wallet are the same thing — the UI labels them "Identity" for people and "wallet" in the underlying API and data model. A wallet is the basic building block of the Triveria ecosystem. Every wallet:

• holds one public/private key pair and the identifier(s) derived from it (a DID, an X.509 certificate, or a raw JWK);
• can hold and present Verifiable Credentials — no configuration required for this.

Configuration adds two further capabilities:

• a wallet becomes an issuer by declaring one or more credential issuers in its configuration;
• a wallet becomes a verifier by declaring one or more credential verifiers.

So every wallet has the holder capability by default, and optionally issuer and/or verifier capabilities — a single wallet can be all three at once. You'll see these as colored chips (holder, issuer, verifier) on wallet cards throughout the UI.

Verifiable Credentials

A Verifiable Credential (VC) is a cryptographically signed, tamper-evident digital statement — the digital equivalent of a diploma, a business registration certificate, or a driving licence. Three parties are involved in every credential's lifecycle:

• the issuer — the wallet that creates and signs the credential;
• the holder — the wallet that receives, stores, and later presents the credential;
• the verifier — the wallet (or party) that requests and checks a presentation of the credential.

A credential moves through a simple lifecycle in Nexus: it starts as a Draft (data entered but not yet signed/issued), becomes Valid once issued and accepted into a holder's wallet, and can later be Revoked by its issuer or shown as Invalid if verification fails.

Credential formats

When you design a credential type you choose how it is technically encoded. Nexus supports three formats:

• SD-JWT VC — a JSON-based format built on Selective Disclosure JWTs. Lets a holder disclose only some claims of a credential during presentation (e.g. prove you're over 18 without revealing your birth date). This is the most common EUDI-facing format.
• JWT VC (VCDM) — the W3C Verifiable Credentials Data Model, serialized as a signed JWT. Common in EBSI-based ecosystems and requires a Schema URL pointing at the credential's JSON Schema.
• MSO Mdoc — the ISO 18013-5 mobile-document format (the same family used for mobile driving licences), CBOR-encoded.

You don't need to be a cryptography expert to pick one — see Credential Types for guidance on when each is used.

Trust frameworks

A wallet's trust framework governs which external registries and rules it plays by, and it is fixed for the lifetime of the wallet — you cannot change it later, only create a new wallet on a different framework.

Trust framework	What it means
NOOP	No external registry. Key-based only. Best for local development, demos, and purely peer-to-peer scenarios where trust doesn't need to be anchored in a public registry.
EBSI	European Blockchain Services Infrastructure. Wallets are identified by a did:ebsi DID and must be onboarded into the EBSI DID Registry before they can issue credentials. EBSI also has a hierarchical accreditation model (see below).
EUDI	The EU Digital Identity Wallet ecosystem (eIDAS 2.0). Wallets are typically X.509-identified and trust is anchored in an ETSI Trusted List rather than a blockchain registry.
IDTL	A certificate/X.509-based trust framework requiring onboarding and a certificate before issuance.

A wallet on any non-NOOP framework must be onboarded to that framework before it can issue credentials; holding and presenting credentials work even before onboarding. See Managing Identities for how onboarding appears in the wallet dashboard.

The EBSI trust chain

EBSI credentials of trust flow down a hierarchy:

EBSI
└── RTAO  (Root Trusted Accreditation Organisation)
    ├── TAO  (Trusted Accreditation Organisation)
    │   └── TI  (Trusted Issuer)
    └── TI  (Trusted Issuer)

Two distinct steps apply to every wallet in this chain, and they're easy to confuse:

• Onboarding registers the wallet's DID in the EBSI DID Registry.
• Accreditation grants the right to act as an RTAO, TAO, or TI — i.e. the right to actually issue certain credential types to others.

A wallet needs both, in that order, before it can act as a trusted issuer within EBSI. Nexus surfaces both steps as buttons/status chips on the wallet dashboard (see Managing Identities).

Identity Templates and Credential Types

Two reusable "building blocks" sit underneath everything you create in Nexus:

• An Identity Template is a saved wallet configuration — trust framework, key type, OIDC settings, and the issuer/verifier definitions a wallet should have. Creating a new wallet is just "pick a template and give it a name."
• A Credential Type is a saved definition of what a credential looks like — its data schema, its format, its icon, and how its fields are laid out on screen. An issuer definition inside a wallet config always points at one Credential Type.

Both live under Building Blocks in the top navigation, and both can be exported as JSON and re-imported (e.g. to move them between environments or share them with a partner organization). See Identity Templates and Credential Types.

Wallet Messaging Protocol (WMP)

Most flows in this guide use a QR code or a URL for a single interaction. WMP is an alternative: a persistent, peer-to-peer connection between two wallets. Once two wallets are connected over WMP, an issuer or verifier can push credential offers and verification requests directly to the holder's wallet — no QR code needed for each individual interaction. Setting up a WMP connection is a one-time "handshake"; see Accepting Credentials for the connection flow and Issuing Credentials / Verifying Credentials for how WMP is used once connected.

The AI Assistant

Nexus includes a conversational assistant ("Nexus Assistant") that can answer questions and, with your confirmation, perform actions on your behalf — issuing a credential, opening a verification request, or creating a new template. It's covered in The Nexus AI Assistant, and its configuration lives under Settings.

With these concepts in hand, continue to Getting Started.