To enhance your understanding of the technical documentation bellow are listed some foundamentals of the Namirial Wallet Platform.
An Organization is the foundational structural entity of the platform. It represents the primary operational domain within which services, configurations, operators, and security settings are defined and managed.
Each Customer is granted access to their own Organization, which serves as their main workspace. From this root context, additional Sub-Organizations can be created to reflect internal structures such as departments, subsidiaries, or business units. Each Organization, including sub-organizations, can configure its own issuance and verification services, operators, credential templates, branding, and policies.
Organizations are structured in a hierarchical tree model:
- The structure starts from a root Organization.
- Each Organization may create one or more child Organizations.
- Parent Organizations have visibility and governance capabilities over their direct and indirect children.
- Child Organizations have no visibility into their parent or sibling Organizations.
- Sibling nodes are mutually isolated.
This tree-based structure ensures that each Organization operates within clearly defined boundaries. While certain configurations (such as services, templates, or branding assets) can be inherited from higher levels in the hierarchy, operational control and visibility remain strictly scoped according to the hierarchy. As a result, each Organization maintains its own configuration and operational autonomy, guaranteeing data segregation, controlled delegation, and separation of responsibilities within the same platform deployment.
Each Organization can have one or more Operators assigned to it. Operators represent the entities authorized to access and manage the platform resources within the scope of the Organization.
Operator permissions are always scoped to the Organization they belong to and, depending on the assigned role, may also extend to child Organizations within the organizational hierarchy. The platform defines two main categories of Operators:
- Human Operators, which access the platform through the administrative web interface (Wallet Studio) to perform configuration, operational, and monitoring activities.
- Technical Operators, which are machine accounts used for system-to-system integrations through the Wallet Gateway APIs.
Each Operator is assigned a specific role, and each role grants a defined set of permissions and allowed actions within the Organization scope.
For a detailed description of Operator roles and permission scopes, refer to Operator roles.
Credential Templates represent the structural foundation for defining the schemas of digital attestations that can be issued or verified through the platform. A credential template defines the data model, format, usage rules, and lifecycle parameters of a credential and can be created both as fully compliant templates, by retriving the schema form the centrall Attestation Rulebook, or as a custom templates, designed to address specific business or regulatory use cases. For each template, the supported data format can be selected (e.g., SD-JWT-based or mDoc)
When creating a credential template, operators can define a comprehensive set of governance and lifecycle parameters that regulate how the credential will behave across issuance and presentation scenarios. A template may be optionally shared with sub-organizations within the hierarchy, enabling controlled reuse across different operational contexts. Its validity period can be configured to determine the timeframe after which the credential becomes expired. The required Level of Assurance (LoA), such as substantial or high, can also be specified, together with usage constraints like single-use behavior, meaning that the credential becomes invalid after its first presentation. In addition, attribute-level rules can be defined, including uniqueness requirements and the distinction between mandatory and optional attributes.
Beyond structural and lifecycle settings, credential templates also support visual customization. Operators can configure branding elements such as colors and the service logo.
Verification templates form the foundation of verification services. Each verification template is linked to an already created credential template, from which it inherits the credential schema and data format. This ensures consistency between what is issued and what can be requested or validated during a presentation flow.
Within a verification template, operatos can configure how the credential attributes should be handled for verification purposes. Attributes defined at credential template level can be marked as mandatory or optional in the context of a specific verification service, allowing the verifier to request only the data strictly required for a given use case.
An Issuance Service is the platform component that enables an Organization to issue credentials through standardized issuance flows using the OID4VCI protocol. Each issuance service is configured by associating a previously defined Credential Template, from which it inherits the credential format and all related credential rules, such as validity period, expiration time, Level of Assurance (LoA), and single-use/disposable behavior. To execute issuance operations, an Issuance Service must be linked to a dedicated Service API Operator. This technical operator is required to authenticate and invoke the backend APIs that generate credential offers and initiate issuance requests, enabling system-to-system integration with the Customer’s infrastructure while ensuring controlled access to the service. In order to become operational, an Issuance Service also requires the configuration of an issuer certificate. If the x5c mechanism is enabled, the platform allows uploading an X.509 certificate so that the issuer certificate chain can be embedded into the issued credential. For testing purposes, self-signed certificates may be used, while production deployments typically rely on trusted X.509 certificates.
Finally, Issuance Services support visual and branding customization, allowing administrators to define logos, colors, and UI-related elements.
A Verification Service enables an Organization to define and manage credential verification workflows in compliance with OID4VP v1.0. It represents the operational component used to request and validate Verifiable Presentations from wallet. A Verification Service must be linked to a dedicated Service API Operator, which is used to authenticate and invoke the backend APIs programmatically. The service configuration also includes protocol-level parameters that control the interaction model, including the request mode, which can be defined using either PEX or DCQL, and the response mode, which can be configured as either unencrypted or encrypted, depending on the security requirements of the relying party. Finally, the Verification Service supports additional trust and certificate-related settings, such as enabling the x509_san_dns mechanism, which can be used to strengthen verifier identification and compliance with certificate-based trust models.