#How to Build an Application using the Walt Enterprise Stack

The Walt Enterprise Stack is a collection of services that are used to build enterprise-ready applications. The APIs are very flexible and can be used to build a variety of applications.

Customers of Walt.id generally build platforms around the Enterprise Stack which simplifies the functionality of the platform to exactly what is required by the end customer. They also generally house additional business logic and integrations with other systems.

Below we will discuss a step by step guide on how to build an application using the Walt Enterprise Stack.

#Table of contents

• Gathering Requirements
• Deciding on an Integration Pattern
• Deploying the Application
• Monitoring the Application
• Support

#Gathering Requirements

The digital identity space is a complex and ever-evolving landscape. There are many different standards, protocols, and frameworks to choose from. It is important to gather requirements from the customer to understand their specific needs and goals.

In terms of credential types, you have the choice of W3C Verifiable Credentials (VC), IETF SD-JWT VC, or ISO mdoc. Different regions and use cases may require different credential types. While they all more or less support the same features, the decision will be mainly driven by the regulatory requirements of the region and the use case.

In terms of exchange protocols, we only support the OpenID family of protocols. This is because we believe it is the most comprehensive and flexible protocol for the job. We currently support the following OpenID protocols:

• OpenID4VP (Draft 14, 20, and v1.0)
• OpenID4VCI (Draft 11, 13, and soon v1.0)

We are currently looking also at supporting the following protocols:

• Digital Credentials API (DCA)
• 18013-7 (ISO mdoc, for proximity flows)

For wallets, we only provide custodial online wallets at the moment. We are looking at adding support for edge wallets in the future.

#Deciding on an Integration Pattern

We generally see most customers building their platform around the Walt.id Enterprise Stack. This allows them to have a single platform that can be used to issue, store, and verify credentials for a variety of use cases. We do not vendor lock any part of our stack, so you can decide to use only the parts of the stack that you need, and then source other parts from other vendors if you need to.

Generally, we see customers build the following features:

• Trust Registry Integrations: The walt stack does not come with a trust registry out of the box, or any integrations with existing trust registries. We do however support API based and certificate based trust registry integrations (The main two types available in the market). When trying to build an ecosystem, you may need to create your own trust registry to whitelist your end-issuers and verifiers. If you are integrating with an existing ecosystem, you will likely need to integrate with their trust registry, which can be simply done using our verification policies which add extra checks to the verification process.
• KYB/KYC Integrations: Our APIs provide a simple way to onboard a new entity into the ecosystem by provisioning them a key, did and wallet. However, many real world use cases require more than just a simple onboarding process. For example, many use cases require the entity to be KYC'd and approved before they can issue credentials. As this is specific to the use case, we do not provide a built in solution for this. Our API should be able to be used as a building block in the onboarding process of your choice.
• Service Provider Integrations: Many customers provide specific portals, SDKs or other services to their end-users. Or in exsiting ecosystems, maybe they need to extend existing offerings to integrate with our APIs. Our APIs are designed to be very flexible and can be used to build these services.
• Schema Registries: When trying to build for an ecosystem, you may need to register schemas for the different credential types to ensure reusability and interoperability across the space. If you are integrating with an existing ecosystem, you are unlikely to need to build a full trust registry, but you may decide to offer simple services to your end-issuers to allow them to quickly map their data to the ecosystem's schemas.
• KMS Integrations: Our APIs support a variety of KMS providers. We support both hardware and software based KMS providers. We have APIs for generating keys within the KMS, but also support BYOK (Bring Your Own Key) scenarios in case integration is required against an existing PKI infrastructure. We also support a variety of key types and algorithms. If you need any other integration, we can build it during the project.
• Wallet Integrations: We provide a simple way to integrate with our wallet API to allow your end-users to store and manage their credentials. This can be then integrated into a new web-based wallet or a mobile wallet app, or used in an existing mobile app or even have no interface at all.

The diagram below shows a typical integration pattern for a customer using the Walt.id Enterprise Stack, mirroring architecture diagrams created by our customers in the past

#Deploying the Application

We provide a docker image for our enterprise stack which includes all the services and dependencies needed to run the stack. This means it is very easy to deploy the stack in your own infrastructure.

We have customers who have deployed our stack in OCI, AWS and Azure, and support the major managed services from those providers. If you need any other integration, we can build it during the project.

We are in the process of extending our offering to also provide the necessary infrastructure as code files (via Terraform) to help with the deployment of the stack in your own infrastructure.

#Using the platform

We provide documentation through our official documentation site (where you are right now).

All the APIs also come with a working swagger interface which can be used to test the APIs directly from the browser.

We also provide an Enteprise UI which contains some of the basic functionality to allow you to test and demo the APIs of the platform.

#Monitoring the Application

We have various ways for you to ingest the logs and metrics from our stack into your centralised observability tools. This means you can use your existing monitoring system to consume the logs and metrics from the stack through our integrations with OpenTelemetry and Prometheus. If any additional requirements are needed, we can implement them as needed.

#Support

Alongside the enterprise license, we provide yearly support contracts for the stack. Generally we are Level 2 or beyond support for incident resolution and feature requests.