Orientation

The Trust Platform issues digital certificates and manages their lifecycle. It is deliberately sector-neutral: it contains no banking, lending, government, or industry-specific logic.

This page explains what the platform does, what it does not do, and where your workflow fits.

What the platform does

The platform provides three core capabilities:

Issuance. An individual or entity enrolled through your organization receives a digital certificate — a cryptographic credential that can be used for signing and encryption. The certificate is issued only on:

• Verification of their identity
• Their explicit confirmation of the certificate details before issuance
• Completion of any statutory requirements

Delivery. Once issued, the credential is delivered to an application running on their device. Delivery is time-limited, attempt-limited, and bound to that specific device and application. The platform does not hold the credential itself after delivery.

Lifecycle management. The platform tracks whether a credential is active, suspended, or revoked. It publishes status changes so other systems can determine whether a signature or encrypted message is trustworthy at a particular moment in time.

What the platform does not do

The platform does not hold your subscriber data. You supply verified identifiers (national ID number, passport, or citizenship document number) and contacts when you enroll someone. The platform uses these to issue the certificate but does not become a general repository of personal information.

The platform does not hold documents or content. Where a signature is involved, only the hash of the document crosses this interface. The document itself remains in your system.

The platform does not enforce your business logic. It does not know about loans, accounts, transactions, permissions, or relationships. You model those in your own system and decide when to request a certificate, accept a signature, or check status.

The platform does not implement your workflow. You decide the sequence and conditions under which certificates are issued, used, and retired. The platform is a building block you compose into your workflow, not a framework that assumes it.

Mapping your workflow

Banking example (not all banks work this way)

If your organization is a bank, you might:

1. Enrollment triggered by your process. A customer completes your account opening or KYC flow. Once verified in your system, you enroll them for a certificate through this platform.

2. Confirmation required. Before the certificate is issued, the customer sees and confirms the details. This is a statutory requirement, not optional.

3. Credential delivered to their device. They install ePahichan (or another authorized app) on their phone. The credential is delivered there and confirmed.

4. Signing and authentication. Your app requests signatures for transactions, forms, or authorization. The customer signs through ePahichan using their credential. The platform does not know what was signed; your app does.

5. Ongoing status checks. Before accepting a signature or transaction, your app checks the certificate status with this platform. If it is revoked or suspended, the transaction is rejected. Status checks are cheap; cache the answer briefly to avoid hammering the API.

6. Lifecycle events. The customer reports their credential compromised, or it expires. The platform notifies your app through webhooks so you can present the right next step.

Government or enterprise example

If your organization verifies and serves citizens or employees, you might:

1. Enrollment at a verification point. A citizen or employee presents identity documents and completes a statutory verification process at a government office or your office.

2. Direct enrollment. Once verified by your staff, you enroll them directly without requiring them to confirm again (the confirmation is part of your in-person verification).

3. Collective distribution. Your system receives the delivery link and sends it to them through SMS, email, or a push notification to ePahichan. They retrieve and confirm receipt.

4. Integration into your service. Your systems use signatures for document authorization, counter-signing, or as evidence of participation or consent in your processes.

Common pattern across all sectors

Regardless of sector:

• You verify. You are responsible for establishing who someone is. The platform does not perform verification; it issues the certificate only if you say you have verified them.
• You decide workflow. The platform issues certificates, delivers them, and tracks status. Your system decides when to request a certificate, what to do with a signature, and when to check status.
• You handle the credential. Once delivered, the credential lives on the subscriber’s device. You never see it. Your app uses the certificate for signing and encryption only through APIs on their device.

The relationship between you and the platform

You are an application consuming the Trust Platform API. You authenticate with a credential and call operations to:

• Enroll a subscriber and request a certificate
• Retrieve delivery instructions
• Check certificate status
• Report compromise
• Handle lifecycle events through webhooks

The subscriber sees only the ePahichan app (or another authorized application) where their credential lives. They do not see or interact with the Trust Platform API directly.

Your organization is a capability-limited participant. You can only request the operations your organization has been granted permission to perform. If you attempt an operation outside your capability set, you receive a 403 with the name of the missing capability — that is deliberately named because “which capability am I missing?” is the most common integration question.

Sector-neutral primitives

The platform supplies:

• Subscriber identity and device binding
• Certificate issuance and lifecycle
• Signing and encryption
• Status and revocation checking
• Audit evidence

Your sector adds everything else: the conditions under which a certificate is requested, the business consequences of a signature, the rules for who may sign what, and the compliance requirements of your domain. The platform is unchanged whether you are a bank, government, enterprise, or service provider.

What happens if you operate outside these boundaries

You will receive clear errors. If you try to do something the platform does not support, you get a named error code and a message that tells you why it failed. Error codes are stable and documented; integrators can build logic around them.

Operational and security risks fall back to you. If you treat the platform as a general data store, mishandle a credential, or log sensitive material, the platform’s contract has not changed but your responsibility has. The platform enforces what it can; the rest is your design.

Compliance and legal liability stay with you. The platform is a building block operated by Radiant InfoTech Nepal as a licensed certificate authority. Your use of it in your sector carries compliance obligations you must understand and meet. Review the certificate policy, privacy statement, and any regulatory guidance for your jurisdiction before integrating.

Next steps

• Read Concepts to understand the entities and their lifecycle
• Review Errors to see what can go wrong and how to resolve it
• Read Events to understand what the platform will tell your system about lifecycle changes
• See the API Reference for every operation and its request/response schema