Integrate digital credentials into existing systems via standards with SOWL.
SOWL is integrated into existing systems via defined interfaces. A business process remains in the source system and is extended with digital credentials. This page shows how the integration is implemented technically and where an entry point is possible.
Integration flow at a glance.
SOWL connects business systems, wallets, and target systems through a clear technical workflow. A decision is made in the source system, issued as a credential, and made available in the wallet. When used, a target system requests the credential, has it verified, and processes the result directly.
HOW THE INTEGRATION WORKS TECHNICALLY.
The integration does not involve replacing existing systems. SOWL connects existing components via defined interfaces and standardized workflows. The following modules address the typical technical entry-point questions.
APIs and protocols
SOWL provides REST APIs for the core integration points and uses OpenID4VCI for the issuance of credentials and OpenID4VP for their presentation and verification. Workflows such as credential offers, presentation requests, and status checks follow clearly defined protocols. This allows existing processes to be extended without implementing custom protocols.
Existing IAM structures
SOWL does not replace existing IAM systems but extends them. OpenID Connect, OAuth2, and SAML remain in place and can continue to be used unchanged. Digital credentials extend existing authentication and authorization decisions without changing the underlying control mechanisms.
Issuance from business systems
Business systems remain authoritative for business decisions and provide the basis for digital credentials. These decisions are passed to the issuer via defined interfaces and converted into signed credentials. This turns an internal verification result into a portable credential that can be used in other systems.
Verification as a service
Verification does not take place in the target system but via the verifier. Signature, integrity, status, and the requirements of the target system are checked automatically in the context of the request. The result is a verified statement that can be processed directly without any verification logic in the target system.
Trust and status verification
The validity of a credential is determined by its signature, current status, and the underlying trust basis. SOWL takes trusted lists, revocation information, and credential versioning into account with every use. This ensures that only valid and trustworthy credentials are accepted.
Operations in existing landscapes
SOWL is designed to operate within existing infrastructures and fits into established operating models. Structured logs with a consistent transaction ID, consistent error behavior, and transactional rollback enable integration into monitoring and logging systems. Versioned APIs ensure that existing integrations remain stable even as the platform continues to evolve.
How the integration gets started.
The integration starts with a clearly defined entry point. Typically this is a single process, such as a KYC flow or an access decision. This process is connected to SOWL via defined interfaces and implemented technically.
On this basis, the integration is extended step by step. Additional systems are connected, further credentials integrated, and existing processes enhanced. SOWL is not introduced in isolation but grows into the existing system landscape.
Integration without disrupting the architecture.
The integration does not require replacing existing systems. The effort depends on the entry point. A first use case can often be implemented within a few weeks. SOWL grows with your system landscape.
Positioning SOWL in your architecture.
In the first conversation, we look at your existing system landscape, the relevant interfaces, and a suitable entry point. You get a technical assessment, not a general product pitch.
