Glossary

Paradym makes it easy to automate your digital identity workflows. The platform was created to make it more accessible for developers to build solutions that use new privacy-preserving technologies and standards to exchange data. Using Paradym, your application can easily issue or verify verifiable credentials, with the purpose of making it more secure and/or user-friendly.

Digital Identity

In itself, digital identity is definitely not a new concept. For as long as people have been communicating over the internet, there has been a need to verify attributes digitally. Your digital identity is a collection of the digital accounts, credentials, and attributes that are connected to you as a person existing in this world.

On the one hand digital identity is something people are often working on protecting. Data privacy, data collection regulations, and other digital privacy protections are set in place by governments, organizations, and companies to protect digital identities. On the other hand people are often working on sharing digital identities, as they are essential for verifying identity, or the authenticity of certain claims in the digital world. The balance between protecting digital identity and sharing it easily is a complex decision for many application builders.

In the past few years new technologies that facilitate the verification and management of digital identities have been getting more popular. The Self-Sovereign Identity (SSI) movement has come up as an increasingly popular way to think about digital identity. SSI promotes the idea that individuals should have full control over their own digital identities, allowing them to manage and share personal information securely, and without reliance on a central authority. Over the years this viewpoint has become the base of a large ecosystem of frameworks, standards, protocols and solutions that enable its technical realization. Paradym is built using some of these frameworks, and supports some of these standards and protocols.

In short, the newest wave in digital identity development is geared towards enhancing privacy, security, and user experience in all types of applications by using verifiable credentials to prove digital identity claims. Paradym functions as a abstraction layer for this, the platform is used to build and host workflows for verifiable data exchange, which can then be used at the applications layer.

Verifiable Credentials

Verifiable credentials are digital attestations that enable people to prove and share information in online interactions. They are digital credentials, often stored in a person or organizations digital wallet, that contain proof about some element.

A one-to-one comparison is often made with physical credentials. The same way you would store your physical ID, drivers license, gym membership card, etc. in you physical wallet, you could store your digital ID, drivers license, gym membership card, etc. in your digital wallet. Important to note is that with verifiable credentials, a person doesn’t have a copy of, or access to their identity proof. They store and manage the actual proof, which contains the information that others can use to verify its authenticity and validity.

A verifiable credential contains information (often about the holder of the credential). It follows a set structure called a schema, ensuring that different verifiable credentials have a common format. The verifiable credential is created based on a set of rules, a credential definition, which functions like a blueprint, ensuring consistency. The credential also includes a digital signature, like a seal, created by the issuing party using their decentralized identifier (DID). This signature acts as proof that the information in the verifiable credential is accurate and hasn’t been tampered with. So, when you share the verifiable credential online, others can verify that it’s genuine and hasn’t been altered.

QEAAs – Qualified Electronic Attestations of Attributes

QEAAs, or Qualified Electronic Attestations of Attributes, are a regulated form of digital attestation under the European Digital Identity (EUDI) framework. They function similarly to Verifiable Credentials (VCs) but have distinct characteristics and legal standing within the eIDAS 2.0 regulation.

Key Characteristics of QEAAs

• Unlike standard Verifiable Credentials, QEAAs hold specific legal weight under eIDAS 2.0. A Qualified Electronic Attestation of Attributes is issued by a Qualified Trust Service Provider (QTSP), ensuring a higher level of trust and compliance with European regulatory standards.
• Each attestation includes a digital signature from the QTSP, which guarantees authenticity and prevents tampering.
• Because (Q)EAAs are backed by QTSPs, they can be widely accepted across different digital identity ecosystems in Europe. They are designed to be interoperable with EUDI Wallets, ensuring seamless use in both public and private sector applications.
• Like Verifiable Credentials, QEAAs are stored in a digital wallet and can be presented when needed. However, due to their legal standing, certain use cases—such as official administrative procedures or regulated digital interactions—may specifically require QEAAs over standard VCs.

Both QEAAs and Verifiable Credentials are digital attestations that allow individuals and organizations to prove specific information about themselves. However, the key difference lies in regulatory oversight and trust assurance.

Issuers, Holders and Verifiers

Interactions, when it comes to verifying proofs, always tend to follow the same pattern between an issuing party, a verifying party and a holding party. This pattern, called the triangle of trust, shows the relationship between these parties wanting to exchange information.

The holder is the entity that holds the credentials, often in a digital wallet. Credentials are issued to the holder, who can then use them to prove claims about themselves. Most often the information in the credentials is in some way about the holder (think about things you would need to prove, like your income, ownership, nationality, licenses, etc.) but there are cases where a holder would need proof about something or someone else. Holders do not have to be natural persons, for example a holder could be an organization holding information about their business and transactions.

An issuing party is an entity that issues credentials to a holder. The issuing party should be in some way capable of issuing these credentials, like a university issuing course completion credentials or a store issuing receipts. In most cases the issuing party has created the schema used to create the verifiable credential, because the schema determines which attributes need to be in a credential and how does credential look in user interfaces.

The verifying party is the entity that wants to request and/or verify information about the holder. The verifying party sends the holder a proof request, and the holder can share a presentation of their proof in return. Within the proof request, the verifier sends a proof template that defines what data they want to verify and how. A presentation of a proof from the holder could be the data from a verifiable credential, it could be a selection of the data, or it could have no identifying data at all through a zero knowledge proof.

Digital Wallet

A digital wallet is a secure digital environment where digital assets are stored and managed. Think for example of a password manager, Apple/Google wallet, or crypto wallets. In the case of digital identity, the digital identity wallet is what stores digital identity information. In this context in the form of verifiable credentials. A digital identity wallet could range all the way from an app on a person’s phone where they collect and manage the personal credentials issued to them, to a system that stores an organizations many credentials.

In the Paradym platform we often use the Paradym digital identity wallet to store the holders verifiable credentials. The Paradym wallet is open source and free to use. It is a mobile wallet, which means it stores credentials on the holders device. Digital identity wallets that store credentials in the cloud instead of on the holders mobile device are called cloud wallets.

Selective Disclosure

The use of verifiable credentials enables some interesting and powerful options when it comes to sharing data. One of the reasons you might want to utilize verifiable credentials is because you could use selective disclosure or zero-knowledge proofs in your solution.

Selective disclosure refers to the disclosure of only select information on the attribute level. So although a credential with many attributes has been issued to the holder, only a selection of those attributes is shared during verification. For example, when using their drivers license to prove their age, a person could only show the relevant data to the question (like photo and birthdate) and leave out other information stored in the same credential (like the types of vehicles they can drive, or in some countries: their address). Selective disclosure is a powerful tool for both holders and verifiers to limit the data shared. There are many methods to achieve selective disclosure depending on the context of the specific cryptographic scheme. Existing cryptographic schemes for selective disclosure are SD-JWT (Selective Disclosure JSON Web Tokens) and Selective Disclosure via BBS+ Signatures. Credential formats with selective disclosure include AnonCreds and W3C credentials.

Predicates and Zero Knowledge Proofs

Predicates and zero-knowledge proofs are both concepts used in the context of selective disclosure but they serve different purposes and operate at different levels of the identity system.

Predicates are logical expressions created by a verifier to define conditions for identity attributes. These conditions can then be evaluated by verifiers to determine whether claims are true without revealing the actual attribute values. In this method, the verifier creates a condition or set of conditions (eg. to receive a certain concert ticket, an individual must by 21+ and have a VIP membership) and can evaluate it during the proof exchange without revealing the actual attribute values.

Zero-knowledge proofs (ZKPs) are cryptographic protocols that allow the holder to prove to the verifier that they know a certain piece of information without revealing the actual information itself. Zero-knowledge proofs are used to authenticate identity attributes without disclosing the attributes themselves. They focus on proving the authenticity of claims and operate at the cryptographic layer.

Credential Template

A credential template is needed if you want to issue a Credential. The template defines the characteristics of your credential, as well as the attributes that it will contain. Once created, a template can be used to issue as many credentials as you want. In the case that GreatUniversity wants to issue digital proofs of graduation, they might create a MasterDiploma template containing fields for the grade, field of study and graduation date to issue to a student.

Presentation template

Assuming that MegaCorp wants to verify a Master Diploma from a future employee, a presentation template defines exactly what elements should be asked of the future employee by MegaCorp, like the grade and the university. A presentation template is defined by the verifier of the information to determine what attributes and/or information the holder of the information should present as proof.

Once created, a template can be used to request as many presentations as you want. In Paradym you can create presentation templates for verifying SD-JWT credentials over OpenID4VC in the UI and through the Api.

Decentralized Identifiers (DIDs)

Decentralized Identifiers (DIDs) are cryptographically verifiable identifiers. When you issue a credential in Paradym it will be signed using a DID, which can be configured when creating a credential template. You can share your DID with verifiers which allow them to ensure the credential was issued by you, or your organization. This identifier is unique and can only be used by you to issue credentials.

How DIDs Work

• DID Creation – A user or organization generates a DID and associates it with a cryptographic key.
• DID Resolution – Verifiers look up the DID document, which contains public keys and service endpoints.
• Authentication & Signing – The owner of the DID uses their private key to sign and verify credentials.
• Verification – A relying party checks the DID document and cryptographic proofs to validate authenticity.

DID Structure

A DID consists of three main parts:

did:<method>:<unique-identifier>

For example, a DID using the did:web method:

did:web:example.com

A typical DID document may look like this:

   {
     "@context": "https://www.w3.org/ns/did/v1",
     "id": "did:web:example.com",
     "authentication": [{
       "id": "did:web:example.com#key-1",
       "type": "Ed25519VerificationKey2020",
       "controller": "did:web:example.com",
       "publicKeyBase58": "Fj4w...X9Kf"
     }],
     "service": [{
       "id": "did:web:example.com#vc",
       "type": "VerifiableCredentialService",
       "serviceEndpoint": "https://example.com/vc"
     }]
   }

X509 Certificates

X.509 certificates are a widely used standard for public key infrastructure (PKI) that enables secure authentication, encryption, and digital signatures. These certificates provide a way to verify the identity of entities, such as individuals, organizations, or servers, using a trusted Certificate Authority (CA).

Paradym supports X.509 certificates for credential verification, allowing verifiers to authenticate the issuer of a credential using well-established PKI mechanisms. This ensures interoperability with existing security infrastructures and regulatory compliance frameworks, such as eIDAS 2.0.

How X.509 Certificates Work

• Issuance – The issuer signs a credential using an X.509 certificate, binding the credential to a cryptographic key.
• Storage – The certificate is embedded in the credential or referenced via a trusted certificate chain.
• Presentation – The holder presents the credential along with the issuer’s X.509 certificate to a verifier.
• Verification – The verifier checks the certificate’s validity, authenticity, and revocation status.

Key Features

• Trusted Identity Verification – Credentials issued with X.509 certificates can be authenticated using a chain of trust.
• Secure Digital Signatures – Enables tamper-proof verification of digital credentials.
• Interoperability – Compatible with existing PKI-based infrastructures, including eIDAS, TLS/SSL, and OpenID4VC.
• Revocation Support – Verifiers can check certificate status via Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs).

Revocation

Revocation is the process of invalidating previously issued verifiable credentials (VCs) so they can no longer be used. In decentralized identity systems, revocation makes sure that credentials can be checked for validity without compromising privacy.

Paradym supports revocation of AnonCreds and revocation of SD-JWTs.

How Revocation Works

• Credential Issuance – An issuer creates a credential and registers its status in a revocation registry or status list.
• Revocation Event – If a credential needs to be revoked (e.g., expired, misused, or reissued), the issuer updates its revocation status.
• Verification – When a verifier checks a credential, they query the revocation registry to confirm its validity.

Selective Disclosure Json Web Token Verifiable Credentials (SD-JWT VCs)

Selective Disclosure JSON Web Token Verifiable Credentials (SD-JWT VCs) are a privacy-preserving credential format that enables users to share only the necessary parts of their credentials while keeping the rest of the data hidden. This makes them particularly useful in scenarios where minimal disclosure is required, such as age verification, access control, and regulatory compliance.

Paradym supports the issuance, verification, and management of SD-JWT VCs in accordance with OpenID4VC standards, ensuring compatibility with the European Digital Identity (EUDI) Wallet and other emerging digital identity ecosystems.

How SD-JWT VCs Work

• Issuance – The issuer creates an SD-JWT VC, signing it with their private key. The credential includes selectively disclosable claims that the holder can reveal on demand.
• Storage – The holder stores the SD-JWT in their digital wallet (e.g., a Paradym-powered EUDI wallet).
• Presentation – When requested, the holder generates a disclosure package that includes only the necessary claims. The verifier checks the integrity of the presented data using the issuer’s signature.
• Verification – The verifier validates the SD-JWT VC against the issuer’s signature and revocation status.

Key Features

• Selective Disclosure – Users can reveal only the attributes required by a verifier while keeping other data private.
• Cryptographic Integrity – SD-JWTs ensure that disclosed data is verifiable without exposing the entire credential.
• Interoperability – Fully compatible with OpenID4VC protocols and eIDAS 2.0 requirements.
• Revocation Support – Can be checked for validity and status updates.

OpenID for Verifiable Credentials (OpenID4VC)

OpenID for Verifiable Credentials (OpenID4VC) is an extension of the OpenID Connect (OIDC) protocol that enables secure issuance, presentation, and verification of verifiable credentials (VCs). It builds upon widely adopted OAuth2 and OIDC standards to provide a streamlined way for users to authenticate and share credentials in a privacy-preserving manner.

Paradym fully supports OpenID4VC for seamless integration with identity providers, verifiers, and credential issuers, ensuring compatibility with eIDAS 2.0 and the European Digital Identity (EUDI) Wallet.

How OpenID4VC Works

• Credential Issuance – The holder requests credentials from an issuer using an OpenID Connect flow.
• Storage – Credentials are stored in a digital wallet (e.g., Paradym EUDI wallet).
• Presentation – The holder shares credentials with a verifier via an OpenID4VC-compliant request.
• Verification – The verifier validates the credentials using the issuer’s signature and trust framework.

Key Features

• Standardized Credential Issuance – Uses OpenID Connect flows for issuing verifiable credentials.
• User-Centric Authentication – Holders control which credentials and attributes are shared.
• Interoperability – Aligns with OpenID Connect, OAuth2, and existing identity federation systems.
• Selective Disclosure – Supports SD-JWTs for minimal data sharing.
• Decentralized and Centralized Support – Works with both decentralized identity (DID-based) and traditional PKI models.

mDoc / ISO/IEC 18013-5

A Mobile Document (mDoc) is a digitally signed, portable identity document designed for secure and verifiable offline and online authentication. It follows the ISO/IEC 18013-5 standard, which defines how mobile driver’s licenses (mDLs) and other identity credentials can be securely stored and shared using mobile devices.

Paradym supports mDoc as part of its verifiable credential ecosystem, enabling organizations to issue and verify digital identity documents that comply with global standards, including eIDAS 2.0 and the European Digital Identity (EUDI) Wallet.

Key Features

• Offline and Online Verification – Supports NFC, QR codes, and BLE for offline authentication, alongside OpenID4VC for online verification.