# Siberia: A Self-Sovereign Identity and Multi-Factor Authentication Framework for Industrial Access
## 2 Materials and Methods
### SSI Module  
SIBERIA adopts an SSI model tailored for private industrial environments, where decentralized and secure identity management is essential. The architecture implements a modular and decentralized identity management system, offering individuals complete control over their identity data while ensuring robust authentication and integrity mechanisms. At the core of the identity infrastructure is the VDR, implemented on a private EOSIO-based blockchain, which manages digital identities and VCs within the system. The choice of EOSIO is based on its implementation of a Delegated Proof-of-Stake (DPoS) consensus mechanism, which enables efficient transaction validation without relying on the costly and slow mining processes typical of other public blockchains. Unlike the public EOSIO blockchain, where the 21 most-voted nodes among all participants act as producer nodes, this private EOSIO blockchain consists of only three nodes, which elect each other to become active producer nodes. In this network, a single administrative account on the EOSIO chain manages the deployment of the smart contract responsible for defining and maintaining three essential SSI registries inspired by the EBSI ecosystem: DID Registry, TIR, and TSR. These registries, implemented on the blockchain, enable the secure and immutable management of decentralized identities, trusted issuers, and credential schemas. Regarding DIDs, SIBERIA closely aligns with the identity model defined by EBSI. For natural persons, SIBERIA adopts the did:key method, following the structure established by EBSI, where identifiers are derived from a public key and encoded using the Base58 BTC format. However, within the SIBERIA context, this type of DID is reserved exclusively for identity holders. Conversely, DIDs associated with legal entities are designated for issuers, who utilize a network-specific DID structure in the format did:siberia:\(<\)method-specific-identifier\(>\). This approach ensures compatibility with existing DID resolution mechanisms while enabling the contextualization and differentiation of the service within the SIBERIA ecosystem. In SIBERIA, the DID Registry is specifically designed to record only the DIDs and DID documents associated with legal entities, namely issuers. Consistent with EBSI recommendations, registering a DID document requires the issuer to first obtain a verifiable authorization to onboard, ensuring a trusted entry into the system. Regarding the TIR, SIBERIA adopts a streamlined approach by reducing the issuer categories from three to two: TAO and TI. The TAO designation is exclusively reserved for SIBERIA's issuer, while all other entities are classified as TI. To be listed as a trusted issuer in the VDR, issuers must present a valid trusted issuer credential. Furthermore, to enhance operational efficiency and privacy, issuers have the option to register a proxy service within the TSR. This proxy facilitates verifiers in remotely querying the status of credentials issued, such as revocation status, without necessitating direct communication with the issuer. In order to register a schema within the TSR, an issuer must first obtain an authorization token granting permission to perform the registration. This serves as a form of access control, ensuring that only authorized issuers can contribute schemas to the registry. Once the issuer holds this token, they may proceed to register one or multiple schemas. Each registered schema represents a formal definition of the structure, attributes, and data formats that VCs issued under that schema must comply with. This mechanism facilitates validation processes and promotes a standardized framework for credential issuance within SIBERIA. To support interaction with the SIBERIA SSI ecosystem, three specialized API interfaces have been developed, each targeting distinct roles within the infrastructure:  
* TAO API: This API is managed by the authorized TAO within the SIBERIA environment and exposes the necessary endpoints for managing onboarding requests to theecosystem.