# Glossary This glossary defines the main concepts, acronyms, and entities referenced throughout the SmartCMS documentation. All terms are derived from the SmartCMS Technical White Paper. ## A ### **API (Application Programming Interface)** A set of mechanisms exposed by SmartCMS to allow external systems to interact with the platform using REST or JSON-over-HTTP services. Supports operations on requests, devices, certificates, operators, offices, and more. ### **Auditing** The subsystem responsible for tracking every significant operation in SmartCMS. Logs include timestamps, operator IDs, action types, and data snapshots. Exportable in CSV, JSON, and XML; can be digitally signed with HSM. ## B ### **Batch Mode** One of the three provisioning flows supported by SmartCMS. Used for mass production of devices via the SmartCMS Batch Station, including certificate batch issuance (if supported by the CA). ### **Bureau Officer (BO)** Operator profile responsible for centralized device production in bureau workflows. Tasks include personalization, packaging, verification, and shipping. ## C ### **CA (Certification Authority)** An entity that issues digital certificates. SmartCMS can interact with multiple CAs through the CA Service Gateway. Examples include InfoCert, PosteCOM, Actalis, Intesa, ArubaPEC. ### **CA Service Gateway** A SmartCMS module that decouples the core system from CA-specific APIs. Allows simultaneous connection to multiple CA backends for issuance, suspension, revocation, renewal. ### **Certificate Lifecycle** The full lifecycle of certificates, including issuance, suspension, reactivation, revocation, and renewal. Managed entirely within SmartCMS. ### **Certificate Profile** A template defining the characteristics of a certificate (key usage, policies, validity, etc.). Selectable by operators during request entry. ## D ### **Delegated Officer (DO)** Operator responsible for token personalization, certificate import, revocation actions, and other advanced tasks. Typically operates within a specific office. ### **Device Customization** The process of personalizing a device graphically (visual printing), electronically (keys/certificates), and at data level (files, metadata). ## E ### **Emergency Codes** Special codes used to revoke or disable tokens in case of theft, loss or compromise. Generated via strong RNG and stored encrypted. ### **Enrolment** The process by which a user is registered, identified, and associated with a cryptographic credential. Might include face‑to‑face recognition, request creation, personalization, and issuance. ## F ### **Fixture** Structured test data (JSON, XML, YAML) that can be loaded into SmartCMS to support testing, debugging, and development. Exportable from a running system. ## H ### **Help Desk (HD)** Operator role responsible for lifecycle actions such as suspension, reactivation, and revocation. Has visibility over all issued devices. ### **HSM (Hardware Security Module)** Secure cryptographic hardware used for strong RNG, certificate operations, and digital signature of audit exports. Integrated within SmartCMS where required. ## I ### **Interactive Mode** A provisioning flow where device personalization and certificate download occur during a live operator session. ### **IoC (Inversion of Control)** Design pattern used in SmartCMS allowing modules to be replaced or extended without recompiling the system. Dependencies are injected via configuration. ## K ### **Key Pair** Public and private key generated during device personalization or remote enrolment. Used for signing, authentication, and encryption. ## L ### **Lifecycle Management** SmartCMS’s ability to manage complete lifecycle of devices (smart cards, tokens) and certificates (issue, suspend, renew, revoke). ## M ### **Migration (Database Migration)** Automated database schema evolution system. Supports forward/backward migrations, transactional safety, and automated rollout during updates. ### **Modularity** Architecture allowing independent modules to be added, removed, or replaced without impacting system core. ## O ### **Operator** A system user with a specific role (RO, DO, BO, SA, HD, AO). Each operator operates within a specific visibility scope (office, division, organization). ### **Organization / Division / Registration Office** Three hierarchical levels used to model complex PKI ecosystems. Offices are the operational units where enrolments and issuance occur. ## P ### **Personal Data Module** A highly customizable data model for defining personal attributes belonging to subscribers and other system entities. Accepts new attributes with validation rules. ### **PIN/PUK** Secret codes used to authenticate device holders and recover access. Managed securely through SmartCMS secret code subsystem. ## R ### **Registration Officer (RO)** Operator responsible for face‑to‑face identification, enrolment data entry, and device delivery. Visibility limited to requests they handled. ### **Revocation** Permanent invalidation of a certificate. Supported individually or in batch and recorded in audit logs. ## S ### **Secret Codes** PIN/PUK and other confidential tokens associated with devices. Stored encrypted in DB. Generated using hardware RNG (smart cards or HSM). ### **Self‑Enrolment** Provisioning mode where user initializes and activates their device via self‑service portal. No operator involvement needed. ### **Self‑Service Portal** Web portal used by end users (Token Holders) to perform certificate renewal, suspension, PIN reset, and virtual token requests. ### **Smartlog** Bit4id subsystem integrated with SmartCMS to log administrator access to archives and logical systems for compliance purposes. ## T ### **Token Holder (TH)** End user of the digital identity device. Can access self-service portal for lifecycle actions such as renewal, suspension, PIN reset. ### **Token Personalization** Electronic initialization of a smart card or USB token, including key generation, certificate import, and security data loading. ## U ### **UKC (Universal KeyChain)** Bit4id’s unified middleware for managing local and remote certificates, signing operations, PKCS#11/CSP/CryptoTokenKit interfaces, and secure authentication. A core component of SmartCMS. ### **UMW (Universal Middleware)** The engine beneath UKC that provides card drivers, PKCS#11 libraries, CSP/KSP modules, PC/SC communication, plugin architecture, and certificate store integration. # Summary This glossary provides all terminology required to understand SmartCMS architecture, workflows, operator roles, cryptographic processes, and administrative controls. Each term reflects the definitions provided in the official SmartCMS white paper.