# Siberia: A Self-Sovereign Identity and Multi-Factor Authentication Framework for Industrial Access
## 3 Results
### Verification and Access Grant  
This phase is responsible for determining whether the holder is indeed the legitimate subject of the shared VCs and whether access to the requested service should be granted. To achieve this, a multi-step verification process is carried out, combining traditional authentication methods, cryptographic credential validation, and secure SASV. As illustrated in Figure 8, the process begins with a classical authentication mechanism, based on the verification of an identifier (email address or DID) and a password previously registered in the service provider's database. If the provided credentials do not match the stored records, access is immediately denied. Following successful traditional authentication, the system proceeds to validate the VP received from the holder. The verifier submits an HTTP request to the SIBERIA API, which handles the VP validation. This involves verifying the cryptographic signature of the holder using their registered public key, ensuring the presentation has not been altered and that the identity of the sender is authentic. Additionally, the VP must comply with the SIBERIA Verifiable Presentation schema, confirming structural and semantic integrity. If the VP passes this validation stage, each of the credentials included within the presentation is individually assessed. The issuer's digital signature is first verified to ensure the credential has been issued by a TI registered in the TIR and that its contents have not been tampered with. The system also checks that the credential conforms to the expected schema and that the issuer is authorized--according to their TIR record--to issue credentials of that specific type. Subsequently, the validity period of the credential is assessed. If the credential includes an explicit expiration date, it is checked against the current timestamp. However, if the credential does not define an expiration date, it is assumed that the issuer maintains an external status registry. In such cases, an HTTP request is sent to the issuer's status proxy--whose endpoint must be registered in the SIBERIA proxy registry--to obtain a status token. This token contains a VC that represents the current status of the original credential. It must pass the same verification checks as any other credential: issuer authentication via the TIR, compliance with the SIBERIA Status Credential schema, and temporal validity. Figure 8: Verification and access grant. If the status credential is valid, its content is then examined. In accordance with the W3C StatusList2021 specification, it includes fields such as the following:  
* id: DID of the credential subject. * type: Expected to be StatusList2021. * statusPurpose: The purpose of the status entry (revocation or suspension)
* encodedList: A compressed bitstring that encodes the status of multiple credentials. * statusListCredential: A reference to the credential containing the status list. The encodedList is used to determine the status of the specific credential based on its index in the list. Following W3C recommendations, the list is GZIP-compressed to optimize storage and transmission. Each credential is assigned a bit: 1 indicates a revoked or suspended credential, while 0 indicates a valid one. Upon decompressing the list and identifying the relevant bit, the system determines whether the credential remains valid. If the credential is confirmed as valid, the verifier then extracts the actual subject data, i.e., the holder's DID and encrypted voiceprint. The final step consists of biometric verification through voice matching. The voice sample recorded by the holder during the service access request is converted to Base64. An HTTP call is then made to the SIBERIA Keys Manager module API in the SASV module to retrieve the voice authentication keys associated with the holder's DID. Using this information, a second HTTP request is sent to perform biometric verification. This verification compares the encrypted voiceprint from the credential with the newly recorded audio sample.