Skip to main content

Glossary

This glossary defines the terms used across the Impierce documentation for UniCore, UniMe and UniTrust. In the articles, a term with a dotted underline shows its short definition when you hover over or focus it.

A​

Activity​

An activity is an entry in UniMe's log of what the user did with an organization: adding a connection, receiving credentials or sharing credentials.

UniMe keeps the activity log on the device, so the user has their own record of which organization received which credential and when. Each activity belongs to a connection.

Architecture and Reference Framework (ARF)​

The Architecture and Reference Framework (ARF) is the technical blueprint for the European Identity Wallet, maintained by the European Commission and the EU member states. It defines the ecosystem roles, credential formats, protocols and the requirements a wallet must meet to be certified.

UniMe implements the ARF's protocols, OpenID4VCI and OpenID4VP, and the SD-JWT credential format. The ARF is published on GitHub, see What is a European Identity Wallet?.

C​

Connection​

A connection is a record of an organization you have interacted with before, identified by its decentralized identifier (DID). Like a trusted contact list, your connections are parties you know, and that history implies some trust.

UniMe and UniTrust both keep connections, but they add them at different moments. UniMe adds a connection after a successful interaction: the user accepts a new issuer or verifier, and the exchange completes. UniTrust adds a connection only after you have inspected the organization's profile and chosen to add it. A UniTrust ecosystem leader invites members over these connections.

In UniMe, a connection stores the organization's name, domain and DID, and the trust evidence UniMe found: domain linkage, public credentials and ecosystem membership. Every activity with the organization is recorded against its connection. UniMe rejects a counterparty whose client identifier is not a DID.

Credential issuer metadata​

Credential issuer metadata is the JSON document an OpenID4VCI issuer publishes at /.well-known/openid-credential-issuer to describe the credentials it offers and how to obtain them.

The metadata lists the issuer's endpoints and its credential configurations, including the format of each credential and display information such as names, logos and colors. UniMe uses the display information to show an offered credential to the user. UniCore serves this document for every issuer it runs, see Technical Details.

Credential offer​

A credential offer is the OpenID4VCI message in which an issuer invites a wallet to collect one or more credentials.

The offer names the issuer and the credentials on offer, and carries the grant the wallet uses to obtain them, for example a pre-authorized code. An offer is usually shown as a QR code or opened as a deep link. It is passed by value or by reference (credential_offer_uri). To create one with UniCore, see Issue a Credential.

D​

A data access consent token (DACT) is a short signed statement, created by UniMe and signed with the user's own wallet key, that allows a verification portal to fetch one specific credential from its issuer for a limited time.

UniMe creates the token when the user shares a credential outside the wallet and stores it at the portal, which answers with a verifiable link. The credential itself stays on the user's device, see What is a verification portal?.

DCQL​

The Digital Credentials Query Language (DCQL) is the JSON query language a verifier uses in an OpenID4VP request to describe which credentials and claims it needs.

A DCQL query names the credential formats, types and claims the verifier accepts, and can offer alternatives. The wallet matches the query against the credentials it holds and lets the user choose what to share. DCQL is defined in the OpenID4VP 1.0 specification. UniCore expresses every verification request as a DCQL query, see Verify a Credential.

Decentralized identifier (DID)​

A decentralized identifier (DID) is a globally unique identifier, such as did:web:example.com, that its owner controls and that resolves to a DID document with public keys and service endpoints.

DIDs are defined by the W3C Decentralized Identifiers specification. The part after did: names the DID method, which decides how the DID is created and resolved. UniMe identifies every connection by a DID, and UniCore supports did:key, did:jwk, did:web and did:iota, see DID Methods.

did:jwk​

did:jwk is a DID method that encodes one public key, as a JSON Web Key (JWK), directly in the identifier. It needs no registry or web server to resolve.

A did:jwk cannot rotate its key or list service endpoints. That makes it a good fit for a person's wallet and a poor fit for an organization. UniMe generates a did:jwk for the user when the wallet is set up. The method is defined in the did:jwk specification.

did:web​

did:web is a DID method that ties a DID to a web domain: did:web:example.com resolves to the DID document at https://example.com/.well-known/did.json.

Because the DID document lives on the organization's own domain, the organization can rotate keys and publish service endpoints, such as public credentials. UniMe requires every OpenID4VCI issuer to publish /.well-known/did.json, which in practice means a did:web. The method is defined in the did:web specification.

DIIP​

The Decentralized Identity Interop Profile (DIIP) is a community profile that fixes one set of credential formats, protocols and DID methods. Wallets, issuers and verifiers that follow it work together out of the box.

DIIP builds on OpenID4VCI, OpenID4VP and SD-JWT. It is maintained by the FIDES community.

Domain linkage​

Domain linkage is the proof that a DID and a web domain belong to the same organization, published as a signed credential at /.well-known/did-configuration.json on the domain.

Domain linkage follows the DIF Well Known DID Configuration specification. UniMe checks it before the user accepts a connection, so the user sees the organization's verified domain instead of a bare DID, see Domain linkage. To set it up for UniCore, see Domain Linkage.

E​

Electronic attestation of attributes (EAA)​

An electronic attestation of attributes (EAA) is the eIDAS 2.0 term for a credential about a person that any organization issues to a European Identity Wallet, such as a diploma, a membership or a license.

Most credentials an organization issues to UniMe are EAAs in this sense. A qualified EAA is issued by a supervised trust service provider and carries legal effect across the EU; person identification data is the government-issued identity.

Ecosystem​

An ecosystem is a group of organizations, run by an ecosystem leader, that publicly state they trust each other. Membership also tells outsiders something: depending on the context, a party can trust an organization more because it belongs to an ecosystem.

Members share a common foundation for exchanging credentials. Issuers and verifiers in the same ecosystem know whose credentials to accept, and an organization can either set up its own ecosystem or join an existing one to build trust at scale.

Ecosystems are published through OpenID Federation, so anyone can check an organization's membership. In UniTrust, a leader creates an ecosystem, invites other UniTrust subscribers as members and can share credential template catalogs with them. When the user meets a new organization, UniMe looks up the ecosystems the organization belongs to and shows each one with its leader and members.

Ecosystem leader​

An ecosystem leader is the organization that creates and runs an ecosystem, decides who becomes a member and acts as the ecosystem's trust anchor.

In UniTrust, the leader invites members over an existing connection, can share credential template catalogs with them and can open a public verification portal for the ecosystem.

eIDAS 2.0​

eIDAS 2.0 is the revised EU regulation on electronic identification and trust services, Regulation (EU) 2024/1183, which requires every EU member state to offer its citizens a European Identity Wallet.

The regulation also sets the rules for organizations that issue or accept credentials from these wallets. UniMe is aligned with eIDAS 2.0, see What is a European Identity Wallet?.

European Business Wallet​

The European Business Wallet is the organizational counterpart of the European Identity Wallet, proposed by the European Commission so companies and public bodies can hold, present and exchange verifiable credentials.

UniTrust gives organizations a business wallet: it holds credentials for the organization and issues and verifies credentials for others.

European Identity Wallet (EUDI Wallet)​

The European Digital Identity (EUDI) Wallet, or European Identity Wallet, is the app that eIDAS 2.0 requires every EU member state to offer. People use it to store and present identity data and other verifiable credentials.

The technical rules are set out in the Architecture and Reference Framework. UniMe is Impierce's open-source European Identity Wallet, aligned with eIDAS 2.0, and Impierce aims to certify it as an EUDI Wallet, see What is a European Identity Wallet?.

European Learning Model (ELM)​

The European Learning Model (ELM) is the EU data model for describing learning achievements, qualifications and the activities behind them, used for European Digital Credentials for Learning.

ELM is maintained by the European Commission as part of Europass. UniMe holds credentials that follow ELM, and UniCore issues them, see Technical Details.

H​

Holder​

The holder is the role, in the issuer, holder and verifier model, of the party that receives verifiable credentials, keeps them in a wallet and presents them to verifiers.

In UniMe the holder is the person using the app, which the UniMe docs call the user. An organization can also be a holder: UniCore and UniTrust can receive and present credentials on its behalf, see Receive Credentials as an Organization.

I​

Issuer​

The issuer is the role, in the issuer, holder and verifier model, of the organization that creates and signs a verifiable credential and delivers it to a holder.

Issuers deliver credentials to wallets such as UniMe with OpenID4VCI. UniCore and UniTrust act as issuers for organizations.

L​

O​

Open Badges 3.0​

Open Badges 3.0 is the 1EdTech standard for digital badges that record achievements, skills and learning, built on the W3C Verifiable Credentials Data Model.

Because version 3.0 is a verifiable credential, a badge can be issued with OpenID4VCI and held in a wallet. The standard is published by 1EdTech. UniMe holds Open Badges 3.0, and UniCore issues them.

OpenID Federation​

OpenID Federation is the OpenID Foundation specification for building trust between organizations through signed statements that chain each participant up to a trust anchor.

UniTrust ecosystems are published as OpenID Federations. When the user meets a new organization, UniMe discovers the trust chains from the organization to its trust anchors and shows each one as an ecosystem. The specification is OpenID Federation 1.0.

OpenID4VCI​

OpenID for Verifiable Credential Issuance (OpenID4VCI) is the OpenID Foundation protocol an issuer uses to deliver verifiable credentials to a wallet.

The issuer sends a credential offer, the wallet obtains an access token and then requests the credential, proving it controls the key the credential is bound to. UniCore implements OpenID4VCI 1.0, and UniMe receives credentials with the same OpenID4VC library, see Technical Details.

OpenID4VP​

OpenID for Verifiable Presentations (OpenID4VP) is the OpenID Foundation protocol a verifier uses to request credentials from a wallet and receive them as a presentation.

The verifier sends an authorization request with a DCQL query, the user chooses what to share, and the wallet returns a signed presentation. UniCore implements OpenID4VP 1.0, and UniMe presents credentials with the same OpenID4VC library, see Technical Details.

P​

Person identification data (PID)​

Person identification data (PID) is the government-issued identity credential in a European Identity Wallet: the digital counterpart of the identity data on a passport or ID card, issued by or on behalf of an EU member state under eIDAS 2.0.

What it contains. The PID of a person always holds their family name, given name, date of birth, place of birth and nationality, plus an expiry date and the issuing authority and country. A member state can add optional attributes such as address, a personal administrative number, a facial portrait, sex, email address, phone number, birth name and age-over checks such as "over 18". An organization can also receive a PID, which holds its legal name and a unique EU identifier.

Legal status. A member state issues PID only after identifying the person at the "high" level of assurance, the same level as a passport or ID card. Every member state must recognize it for online identification, and public services across the EU must accept it where they require electronic identification. PID is not a travel document: it does not replace a passport or ID card at a border, and whether a person can show it in place of a physical ID in person is for each member state to decide.

Only a certified European Identity Wallet can hold PID. UniMe starts without it: users begin with self-issued credentials and add credentials from organizations over time.

Public credentials​

Public credentials are credentials an organization holds itself and publishes from its DID document, such as an accreditation or a registration, so that anyone who meets the organization can check what it has been certified for.

The standard underneath is DIF Linked Verifiable Presentations: the DID document links to a presentation of the credentials, signed by the organization. UniMe shows an organization's public credentials on the accept-connection screen after checking each one, see Connections & Trust. To publish them with UniTrust, see Linked Verifiable Presentations.

Presentation​

A presentation is the signed package in which a holder shares one or more credentials, or selected claims from them, with a verifier.

The holder's signature over the presentation proves that the credentials were not copied from someone else, and a nonce from the verifier ties the presentation to one request. Wallets send presentations with OpenID4VP.

Q​

Qualified electronic attestation of attributes (QEAA)​

A qualified electronic attestation of attributes (QEAA) is an electronic attestation of attributes issued by a qualified trust service provider supervised under eIDAS 2.0. It has the same legal effect as its paper equivalent across the EU.

Organizations that are not qualified trust service providers issue ordinary EAAs, which is what most issuers do with UniMe today.

R​

Relying party​

A relying party is the term eIDAS 2.0 and the OpenID specifications use for a verifier: an organization that asks a wallet for credentials and checks them.

Under eIDAS 2.0 a relying party registers in its member state and states which data it asks for, so wallet users see who is asking and why. UniMe shows the organization behind every request as a connection.

Revocation​

Revocation is an issuer declaring that a credential it signed is no longer valid, by publishing a new status for it instead of changing the credential itself.

The credential stays in the wallet and the issuer learns nothing about where it was used. UniMe shows a revoked credential as "Revoked" and checks status through the OAuth Token Status List, see Connections & Trust. An issuer can withdraw a credential only by revoking it or issuing a replacement.

S​

SD-JWT​

Selective Disclosure for JSON Web Tokens (SD-JWT) is an IETF credential format in which each claim can be disclosed or withheld separately. A holder shares only what a verifier asks for.

UniMe and UniCore support SD-JWT credentials with the format identifiers vc+sd-jwt (W3C Verifiable Credentials secured with SD-JWT) and dc+sd-jwt (SD-JWT VC). The base format is defined by the IETF OAuth working group.

Selective disclosure​

Selective disclosure is the ability of a holder to share only some claims of a credential, such as a date of birth without the address. The verifier can still check the issuer's signature.

Selective disclosure depends on the credential format: SD-JWT supports it, while a credential secured as a plain JWT (jwt_vc_json) is always shared whole.

Self-issued credential​

A self-issued credential is a credential the user creates and signs with their own DID, instead of receiving it from an issuer, for example their profile or address.

Self-issued credentials hold self-attested data: information the user states about themselves without a third party vouching for it. A verifier can tell them apart from issued credentials because the issuer is the user's own DID. UniMe creates self-issued credentials as SD-JWT credentials, so the user can disclose single fields.

SIOPv2​

Self-Issued OpenID Provider v2 (SIOPv2) is an OpenID Foundation specification that lets a wallet act as its own OpenID provider. A person signs in to a website with a key they control, not an account at an identity provider.

The wallet answers the request with an ID Token signed with the user's DID. UniCore sends a SIOPv2 request when a verification request contains no DCQL query, and UniMe answers it. The specification is SIOPv2.

Stronghold​

Stronghold is an open-source Rust library that keeps secrets, such as private keys, in an encrypted, password-protected store.

UniMe keeps the user's keys and credentials in a Stronghold file on the device, unlocked with the user's password. UniCore keeps its signing keys in a Stronghold vault. The library is available on GitHub.

T​

Token Status List​

The OAuth Token Status List is an IETF mechanism in which an issuer publishes the status of many credentials as one compact, signed list. Each credential names the list and its own position in it.

A wallet or verifier fetches the list and reads the position to see whether the credential is valid, revoked or suspended, without telling the issuer which credential it checked. UniMe reads the status claim from the credential and fetches the list from the device, see Connections & Trust. The mechanism is defined by the IETF OAuth working group.

Trust anchor​

A trust anchor is the entity at the top of an OpenID Federation whose statements everyone in the federation accepts. Trust in any member can be traced back to it.

In a UniTrust ecosystem, the ecosystem leader is the trust anchor. UniMe shows each trust anchor it finds for an organization as one ecosystem.

V​

Verifiable credential​

A verifiable credential is a digital statement about a subject, such as a diploma or a membership, signed by an issuer. Anyone can check who issued it and that it was not changed.

Verifiable credentials are tamper-resistant and instantly verifiable. Their data model is the W3C Verifiable Credentials Data Model 2.0, and they are secured in formats such as jwt_vc_json and SD-JWT.

A verifiable link is a public URL to a credential on an ecosystem leader's verification portal, so anyone can check the credential in a normal browser without a wallet.

A UniMe user gets a verifiable link by sharing a credential outside the wallet, today through "Share to LinkedIn". The link is backed by a DACT and reused on later shares, see What is a verification portal?. UniTrust calls the feature verifiable links.

Verification portal​

A verification portal is a public website, hosted by an ecosystem leader with UniTrust, where anyone can check a credential in a normal browser without a wallet or a UniTrust subscription.

When a UniMe user shares a credential outside the wallet, UniMe stores a data access consent token (DACT) at the portal and posts a verifiable link. The viewer consents, and the portal fetches a copy of the credential from the original issuer and verifies it on screen, see What is a verification portal?.

Verifier​

The verifier is the role, in the issuer, holder and verifier model, of the party that requests credentials from a holder and checks them.

A verifier checks the issuer's signature, the holder's signature on the presentation and the credential's status. Verifiers request credentials from wallets such as UniMe with OpenID4VP. UniCore and UniTrust act as verifiers for organizations. OpenID specifications call the verifier a relying party.