The Community Stack

It has always been our goal to provide developers and organizations with great tools, so they can focus on delivering holistic identity solutions. Taking the lessons learned from previous products, we decided to redesign our current offering, resulting in what we now call The Community Stack. A collection of open-source products providing everything to launch any identity solution with ease. You can learn more about it here.

Transition

Starting from December 2023, the SSI-Kit will halt feature enhancements, leading to a complete discontinuation planned for end-Q3 2024. It's essential to plan your transition to the new stack effectively. The table below indicates which components of the SSI-Kit are already supported in the new stack.

• For Kotlin/Java projects where SSI-Kit was used as a native dependency, utilize the provided Library for equivalent features in the new stack. •

• If you employed the REST APIs, simply switch to the supplied API in the new stack.

If you have any question, please reach out.

This section elaborates the theory behind the SSI Kit:

• SSI Kit | Basics - Learn what the SSI Kit is and what it does.

• SSI Flavors & Ecosystems - Learn which SSI flavors and identity ecosystems we support.

• Architecture - Explore the SSI Kit's multi-layered architecture and components.

• Use Cases - Explore use cases you can implement with the SSI Kit.

• SSI-Kit feature list - Explore all features in an overview list.

Our products are agnostic towards the underlying technologies used to implement Trust Registries, which means that the SSI Kit is potentially compatible with any type of Trust Registry.

The SSI Kit supports:

• Permissionless Blockchains (e.g. Ethereum),

• Permissioned Blockchains (e.g. Ethereum Enterprise/Hyperledger Besu),

• Domain Name Service (DNS),

• Pure peer-to-peer approaches that do not require Registries.

Note that we are continuously adding support for new Registries and underlying technologies.

You can learn more about Trust Registries here.

Here are the most important things you need to know about the SSI Kit:

• It is written in Kotlin/Java. It can be directly integrated (Maven/Gradle dependency) or run as RESTful web-service. A CLI tool allows you to run all functions manually.

• It is open source (Apache 2). You can use the code for free and without strings attached.

• It is a holistic solution that allows you to build use cases “end-to-end”. There is no need to research, combine or tweak different libraries to build pilots or production systems.

• It abstracts complexity and low-level functionality via different interfaces (CLI, APIs). Additional services facilitate development and integration (e.g. Issuer and Verifier Portals).

• It is modular, composable and built on open standards allowing you to customize and extend functionality with your own or third party implementations and to preventing lock-in.

• It is flexible in a sense that you can deploy and run it on-premise, in your (multi) cloud environment or as a library in your application.

• It enables you to use different identity ecosystems like Europe’s emerging identity ecosystem (EBSI, ESSIF) in anticipation of a multi-ecosystem future.

We believe in a multi-ecosystem future.

This is why we built an abstraction layer for ecosystem-specific operations and business logic. The idea is to support any ecosystem with a single solution that does not put any additional burden on developers. As a result, you can use our solutions to participate in different ecosystems without having to switch between different technical implementations.

We currently support:

• EBSI/ESSIF (EU's new decentralized identity ecosystem)

• Gaia-X (EU's new cloud infrastructure)

• Velocity Network

• cheqd Network

• IOTA

Note that we are continuously adding new ecosystems.

Signatory | For Issuers

Signatory allows you to digitize paper credentials and automate data provision to your stakeholders.

It provides all functionality required by “Issuers”. For example:

• Process and authenticate data requests by people or organisations,

• Import data (from local storage or third parties),

• Create re-usable VC templates,

• Create VCs in different formats (e.g. JSON/JWT, JSON-LD),

• Sign VCs using different key types (e.g. ed25519, secp256K1, RSA),

• Manage the lifecycle of VCs (e.g. revocation).

• Issue VCs (e.g. via OIDC/SIOP)

Custodian | For Holders

Custodian is a secure data hub for people and organizations. It provides all functionality required by “Holders”. For example:

• Interact with Registries (read, write)

• Create, store, manage keys, data (DIDs, VCs) and other secrets,

• Request and import data (VCs) from third parties,

• Selectively disclose data (VCs/VPs) for authentication and identification,

• Manage consent and data access in a user-centric fashion.

Auditor | For Verifiers

Auditor allows you to verify your stakeholders’ identity data and offer frictionless access to services or products. It provides all functionality required by “Verifiers”. For example:

• request data (VCs/VPs) from stakeholders,

• verify data (VCs/VPs; incl. integrity, validity, provenance, authenticity),

• trigger pre-defined actions following the verification.

Verification Policies

The verification steps can be dynamically configured by passing "verification policies" to each verification attempt.

The SSI Kit comes with the following set of built-in verification polices:

• SignaturePolicy: Loads or resolves DID, loads public key and verifies the credentials signature.

• JsonSchemaPolicy: Validates the credential against the JSON schema.

• TrustedSchemaRegistryPolicy: Checks if the JSON schema is anchored in the EBSI Trusted Schema Registry.

• TrustedIssuerDidPolicy: Checks if the issuer DID is anchored on the EBSI DID registry.

• TrustedIssuerRegistryPolicy: Checks if the issuer got inserted in the EBSI TIR (Trusted Issuer Registry).

• TrustedSubjectDidPolicy: Checks if the issuer DID is anchored on the EBSI DID registry.

• IssuedDateBeforePolicy: Checks if issued date is in the past.

• ValidFromBeforePolicy: Checks if valid-from date is in the past.

• ExpirationDateAfterPolicy: Checks if expiration-date is in the futrue.

• CredentialStatusPolicy: Checks if credential is revoked based on the credential-status list.

This documentation will help you understand how the SSI Kit works and how you can use it. However, it presumes a certain level of knowledge about Self-Sovereign Identity (SSI) so

• if you are already familiar with SSI, you can jump to the introduction of the SSI Kit.

• if you are new to SSI, please continue with our introduction to Self-Sovereign Identity.

The SSI Kit offers everything you need to use Self-Sovereign Identity (SSI) with ease.

The following sections elaborate the SSI Kit's unique properties, enabled functionality and components.

The SSI Kit abstracts complexity for developers by following a "multi-stack approach" that enables you to use different implementations or "flavours" of SSI.

As a result, you can participate in different identity ecosystems (e.g. EBSI/ESSIF, Gaia-X, Velocity Network, cheqd and IOTA) and avoid technology-related lock-in effects.

Based on our Introduction to Self-Sovereign Identity (SSI), we distinguish the following concepts or building blocks:

Read on to learn which concrete technologies and implementations we support on the level of

• Trust Registries

• Keys

• Decentralized Identifiers (DIDs)

• Verifiable Credentials (VCs)

• Data Exchange Protocols

The SSI Kit establishes an identity infrastructure layer for any use case in any industry. Its core services are in the scope of:

• Registry Interactions (e.g. read, write; agnostic towards the underlying tech e.g. DLT, DNS)

• Key Management (e.g. generate, sign, import, export, manage lifecycle)

• Decentralized Identifier (DID) operations (e.g. register, resolve, manage lifecycle)

• Verifiable Credential/Presentations (VC, VP) operations (e.g. create, issue, present, verify)

• Ecosystem specific use cases (e.g. onboarding, data exchange and monetization)

Illustration:

Cryptographic keys convey control over digital identities and enable core functionality such as encryption and authentication.

The SSI Kit supports:

• EdDSA / ed25519

• ECDSA / secp256k1

• ECDSA / secp256r1

• RSA

Note that we are continuously adding support for new key types.

This software-layer holds a set of generic core services for common SSI and cryptographic functions. The services are in the scope of key management, decentralized identifiers, verifiable credentials and data storage.

The following is a short summary of the interfaces available. The detailed functions are described in the documentation further on.

Key Interfaces

Handles keys and cryptographic operations like the generation of signatures (e.g. linked data, JWT) with signature types such as ES256K or EdDSA.

Keys can be stored in a file and database keystore, which is extendable to HSMs and WebKMS.

DID Interfaces

Abstracts common functionality related to Decentralised Identifiers (DIDs, DID Documents) for methods like “did:web”, “did:key”, “did:ebsi”.

Credential Interfaces

Abstracts common functionality related to Verifiable Credentials (VCs) and Verifiable Presentations (VPs) in different formats like JSON and JSON-LD.

Our open source solutions enable you to use different types of DIDs and different identity ecosystems. Every relevant functionality is supported from the generation of DIDs and DID Documents to anchoring or resolving them on/from Registries.

We currently support the following DID methods:

• did:ebsi

• did:web

• did:key

• did:jwk

• did:iota

• did:cheqd

Note that we are continuously adding support for new DID methods.

Verifiable Credentials (VCs) are digital identity documents that can easily and securely be shared with and verified (incl. validity, integrity, authenticity, provenance) by anyone in a privacy preserving way. Importantly, they are never (!) stored on a blockchain due to privacy and compliance reasons.

The SSI Kit supports W3C Verifiable Credentials in different formats:

• JSON / JWT

• JSON-LD

Note that we are continuously adding support for new VC types and formats.

The architecture of the SSI Kit consists of three layers:

1. Low-Level Services Abstraction: Abstracts complex, low-level operations (e.g. cryptography, key management, digital signatures, data storage).

2. Ecosystem Abstraction: Abstracts ecosystem-specific requirements based on the relevant technical and governance frameworks (e.g. SSI flavors, business logic, policies).

3. High-Level Interfaces / APIs: Provides high-level interfaces that hide complexity and facilitate usage for developers.

Also, the architecture allows for the integration of third party solutions throughout the stack. For example:

• Key storage (e.g. HSM, WebKMS)

• Data storage (e.g. identity hubs, confidential storage)

• Registries (e.g. blockchains, DNS)

This architectural openness prevents vendor lock-in and allows you to build SSI-based solutions that meet your unique requirements.

Illustration:

Read on to explore all three abstraction layers in more detail.