SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS

Abstract

Secure communication is established between a user computing device and a server computing device. An enrollment request is received from a user computing device, configured via a distributed client software application, and processed. This enrollment request can be used to enroll the user computing device on a network and includes an initial encrypted partial biometric vector associated with a user. A subsequent authentication request, which includes a second encrypted partial biometric vector associated with a user of the user computing device, is then processed. A comparison is performed between the initial encrypted partial biometric vector and the second encrypted partial biometric vector, and a value representing the comparison is generated and transmitted to the user computing device.The user's computing device is authenticated when the value is above a minimum threshold.

Description

SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS Cross-reference to Related Applications This patent application is a continuation in part of, and is based upon, and claims priority to, United States Patent Application Serial Number 15 / 800,748, filed November 1, 2017, entitled “SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS,” which is based upon and claims priority to United States Patent Application Serial Number 15 / 243,411, filed August 22, 2016, now Patent No.9,838,388, which claims priority to United States Patent Application Serial Number 62 / 208,328, entitled “SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS” filed on August 21, 2015, and which claims priority to United States Patent Application Serial Number 62 / 241,392, filed on October 14, 2015, and this application is a continuation in part of United States Patent Application Serial Number 16 / 378,044, filed on April 8, 2019, which claims priority to United States Patent Application No. 15 / 592,542 filed on May 11, 2017, now United States Patent No. 10,255,040, each of which is incorporated into this document by reference as if set forth in its entirety herein. Field of Invention The present invention relates to security, and more particularly to systems and methods for the identification or authentication of a user. Background of the Invention Information of all kinds continues to be stored and accessed remotely, such as on storage devices accessible through data communication networks. For example, many individuals and businesses store and access financial, medical, and health information, as well as information about goods and services, purchases, entertainment, and multimedia information via the internet or other communication networks. In addition to accessing information, users can participate in monetary transactions (e.g., purchases, transfers, sales, or similar activities) by using a compromised identity. In a typical scenario, a user registers to access the information and then submits a username and password to log in and access it.Ensuring access to (and from) such information and data stored on a data or communication network remains a primary concern. Furthermore, most user authentication methods and identity verification systems rely on a centralized database. This data storage presents a single point of compromise from a security perspective. If this system is compromised, it poses a direct threat to users' digital identities. Therefore, what is needed in the technique are computer-implemented systems, methods, and approaches that overcome the security vulnerabilities inherent in such user identity systems. Brief Description of the Invention The computer systems, methods, and products described in this document are aimed at user authentication where there is no single point of compromise of user identities. For example, a computer-implemented method is provided for registering an identity with an authentication system. The method involves receiving, from a mobile computing device via a data communication network, at least one encrypted cryptographic share consisting of an initial biometric vector (IBV) and a public key from a first public-private key pair generated mathematically through the use of seeds, where the at least one encrypted cryptographic share has been encrypted using a private key from the first public-private key pair.The described method also includes a step for generating a first identity data set that includes at least one authorization system signature, where the signature is a digital signature, the public key of the first public-private key pair, and at least one encrypted cryptographic share; and storing the first identity data set in at least one remote storage location. In one or more additional implementations, the described method includes a step for generating an identity reference value that is associated with the first identity data set, where the identity reference value resolves to the storage location of the first identity data set and is cryptographically associated with the first generated identity data set.As an additional example, the method described also includes distributing, among each of a plurality of ledgers stored on the respective nodes, a transaction record that includes at least the identity reference value and provides the mobile computing device with at least the identity reference value. In one or more further implementations of this application, a system for providing a user with access to a resource provider includes a processor having memory and configured by means of one or more modules to receive, from a mobile computing device via a data communication network, at least one identity reference value associated with a first identity data set, wherein the identity reference value resolves the storage location of the first identity data set and is cryptographically associated with the first identity data set, wherein the first identity data set includes at least one authorization system-specific data value,A public key from a public-private enrollment key pair is mathematically generated using a seed and at least one remote encrypted cryptographic share of an initial biometric vector of a user requesting access. The system processor is further configured to receive a signature value from the authorization system, where the signature is a digital signature and the public key from the public-private enrollment key pair is the public key. Using the received data, the system is configured to locate, among a plurality of ledgers stored on the respective nodes, a transaction record that includes at least the identity reference value, and to determine, from the located transaction record, a storage location for a corresponding first set of identity data. In one particular implementation,The system also includes a processor configured to access the first cryptographically associated identity data set and to verify the signature value of the authorization system and the enrollment public key of the first identity data set. In a further implementation, a system processor is configured to receive, from the mobile computing device, a current biometric vector and a locally encrypted biometric cryptographic share, and to decrypt the received locally encrypted cryptographic share and the remotely encrypted cryptographic share using the public key of the enrollment public-private key pair. In this case,The processor of the described system can combine the decrypted local cryptographic share and the decrypted stored cryptographic share to form a combined cryptographic vector and can compare the combined cryptographic vector with the current biometric vector. When the combined cryptographic vector matches the current biometric vector, the processor of the described system can instruct the resource provider to grant the user access to the resource. In one or more implementations of this application, secure communication is provided between a user computing device and a server computing device. An enrollment request is received from a user computing device configured with a distributed client software application. The enrollment request can be used to enroll the user computing device on a network and includes an initial encrypted partial biometric vector associated with a user. A subsequently received authentication request is processed, which includes a second encrypted partial biometric vector associated with a user of the user computing device. A comparison is performed between the initial encrypted partial biometric vector and the second encrypted partial biometric vector, and a value representing the comparison is generated and transmitted to the user computing device.The user's computing device is authenticated when the value is above a minimum threshold. In one or more implementations, secure communication is provided between a user computing device and a server computing device. An enrollment request received from a user computing device configured with a distributed client software application is processed. The enrollment request can be used to enroll the user computing device on a network and includes the first portion of a first biometric vector associated with a user. The first portion of the first biometric vector is stored, and a subsequently received authentication request is processed, which includes a second biometric vector and a second portion of the first biometric vector. The first and second portions are combined and compared to the second biometric vector. A value representing the comparison is generated and transmitted to the user computing device.The user's computing device is authenticated when the value is above a minimum threshold. In one or more implementations, a certificate is provided that is included in the registration application and the authentication request, in which the processing of the authentication request includes determining that the certificate is up-to-date and not revoked. In one or more implementations, an intrusion detection system is provided that actively monitors and prevents certificate spoofing, including certificate replication. In one or more implementations, the processing of the authentication request includes performing at least one matching operation in the cipherspace as a function of one-way encryption. One-way encryption can be carried out through the use of a random one-way keypad. In one or more implementations, role collection is provided and defined by one or more rules for access to a digital asset, and the server computing device grants or denies access to the digital asset by the user computing device as a function of role collection. Access can be provided as a function of at least one of discretionary access control and one of mandatory access control. In one or more implementations, the server computing device processes a second enrollment request received from the user computing device configured with a distributed client software application. This second enrollment request can be used to enroll a second user of the user computing device on the network, and it includes a second encrypted initial biometric vector (IBV) associated with a user of the user computing device. Processing the second enrollment request includes storing the second encrypted partial IBV on a non-transient, readable processor medium accessible by, or part of, the server computing device. In one or more implementations, the server computing device may revoke a user's registration. Other features and advantages of the present invention will be made apparent in the following description of the invention with reference to the accompanying drawings. Brief Description of the Drawings / Figures Other aspects of this disclosure will be more easily appreciated by examining the detailed description of its various forms, which are described below, when taken together with the accompanying drawings, in which: Figure 1 is a block diagram illustrating a plurality of devices and components with one or more implementations of the present application. Figures 2 to 6 illustrate the devices and the flow of information between them in relation to an example of a BOPS implementation. Figure 7A illustrates the devices and steps associated with a sample enrollment process with special emphasis on data confidentiality, according to one or more implementations. Figure 7B illustrates an example of an administrative console provided in a user interface in accordance with this application. Figure 8 illustrates an overview, including data access and exchange, in relation to a registration process. Figure 9 illustrates the components of a security architecture according to one or more implementations of this application. Figures 10A and 10B illustrate the devices and steps associated with two respective and alternative registration processes, according to one or more implementations of this application. Figure 11 is a block diagram illustrating the possible requirements and examples associated with the different levels of a Genesis process, according to the present application. Figure 12 illustrates an example of the information flow that is associated with an initial biometric vector during the enrollment and authentication processes. Figure 13 illustrates an example of visual cryptography (VC) being implemented in connection with this application. Figure 14 illustrates an example of the overlap of two shared resources (2, 2) in a visual cryptography scheme (VCS) where each bit is encrypted in the shared resources, in relation to an example implementation of BOPS. Figure 15 illustrates an instance of a role hierarchy according to the present application. Figure 16 is a block diagram illustrating the devices and transmission flow in relation to replay prevention, according to an example implementation. Figure 17 is a high-level flow illustrating the steps associated with matching a token to a sample implementation. Figure 18 illustrates examples of devices and features in relation to a Genesis process in a many-to-many relationship. Figure 19A shows several users initiating a sample enrollment process on a single client device. Figure 19B illustrates an example of a user initiating an authentication session from a client device, which stores information regarding multiple user accounts. Figure 19C illustrates the example steps that are associated with revoking a user's account. Figure 20A is a simplified diagram showing the steps that are associated with the initialization, verification, and confirmation of a client certificate between a client device and a BOPS server. Figure 20B illustrates an example of client certificate registration in relation to a third-party server and a BOPS server; Figure 21 illustrates an example of the QR code authentication flow, according to an example implementation of this application. Figure 22 illustrates an example of the devices and features related to the authentication process through the use of distributed ledgers and identity hubs. Figure 23 is a block diagram that represents the devices and connections between users and authentication providers in the enrollment and resource access processes. Figure 24 is a flowchart that illustrates an example of a user initiating an authentication session from a client device, which stores information for authentication purposes. Figure 25 is a simplified diagram showing the steps that are associated with enrolling a user with an identity provider. Figure 26 is a flowchart illustrating an example of a user gaining access to a resource through the use of an authentication verifier. Figure 27A is a simplified diagram showing the steps that are associated with verifying a user's identity with an identity verifier. Figure 27B is a variation of the simplified diagram in Figure 27A, which shows the steps that are associated with verifying a user's identity with an identity verifier. Figure 28 is an alternative simplified diagram showing the steps that are associated with verifying a user's identity with an identity verifier. Figure 29 is a flowchart showing the steps that are associated with an implementation of user identity verification with an identity verification system described in this document. Detailed Description of the Invention As an overview and introduction, the systems, methods, processes, and IT products described herein target and utilize a decentralized biometric credential storage system for digital representations of identities through the use of distributed ledgers (e.g., blockchains). Currently, in the technical field of user identification, users are required to relinquish personal information such as credit histories, credentials such as birth certificates, or biometric data such as fingerprint templates to a third party with a centralized database. This new decentralized ecosystem for private and secure identity management is being implemented by various projects as a replacement for traditional identity verification systems.In order to overcome this problem inherent in the use of identifications on various networks (e.g., the Internet), this document describes several approaches to allow end users, rather than traditional centralizing organizations, to establish control over user identity data when establishing or participating in exchanges across networks. Pursuant to one or more implementations of this patent application, a new set of standards, referred to herein generally as the Biometric Open Protocol Standards (BOPS), is provided. When combined with a user-controlled authentication system, this standard enables user authentication where user identification information is protected by the user rather than by a central authority. One or more BOPS implementations may provide one or more modules for identity assertion, role collection, multi-level access control, assurance, and auditing. Figure 1 illustrates an example of a hardware arrangement 100 and shows data communication in relation to one or more BOPS implementations. The arrangement 100 may include one or more software applications that configure multiple computing devices, such as a client device (e.g., a smartphone or mobile device) 104, a server computing device (referred to herein generally as a BOPS server) 102, a third-party server 106, and an intrusion detection system (IDS) that may include a plurality of computing devices 112, to support and enable the functionality shown and described herein. In addition, the BOPS server 102 may be in communication with, or connected to, the health monitoring device 108 and the analytical engine device 110.Both device 108 and 110 can be configured as part of the BOPS 102 server or they can be individual devices. The following is a non-exhaustive list of abbreviations and acronyms referenced herein: admin = administrator; AOP = appearance-oriented programming; API = application programming interface; AWS = Amazon Web Services; app = client application; BOPS = open protocol biometric standard; CPU = central processing unit; CBV = biometric current identifier; CSRF = cross-site request forgery; HSM = hardware security module; ID = identifier; IDS = intrusion detection system; IBV = initial biometric vector; IP = Internet protocol; JSON = JavaScript object notation; LDAP = lightweight directory access protocol; MAC = mandatory access control; MCA = mobile client application; NSA = National Security Agency (USA); QR code = quick response code; RDBMS = relational database management system;REST = Representational State Transfer; SSL = Secure Sockets Layer; TCSEC = Trusted Computing Systems Evaluation Criteria; TEE = Trusted Execution Environment; TPM = Trusted Platform Module; TLS = Transport Layer Security; URL = Uniform Resource Identifier; XNTP = Extended Network Time Protocol; XOR = Exclusive OR Binary Operation; 1:M = One-to-Many; 4F = Four Fingers, a patented biometric technology; 5-tuple = Five Tuple Data Parameters. One advantage of this application is that one or more respective BOPS implementations can include the components to provide the functionality and can work with, or replace, an enterprise's existing components, thereby providing integration with current operating environments in a relatively short time. Furthermore, one or more respective BOPS implementations provide continuous protection of forms, such as granting access to sensitive and private resources.Service-level security can be provided in BOPS implementations that meet or exceed accepted goals, at least in part as a function of one or more application programming interfaces (APIs) that support the implementations as a point-and-cut mechanism to add appropriate security to production systems as well as systems under development. One or more BOPS implementations may include a BOPS server 102 that can receive, via one or more data communication networks, a biometric vector from a client device 104, referred to herein as the initial biometric vector (IBV), and may divide the vector according to an algorithm into a plurality of parts associated with identification. Regardless of the number of parts, the IBV may be encrypted, even in a keyless manner, and a subsequent biometric matching process may optionally be performed on the client device 104 or the server 102, for example, as specified by an administrative parameter. One or more BOPS implementations can be deployed in various online environments, such as in a public cloud (e.g., Amazon Web Services) or in a private cloud. Based on the organizational structure and functionality of the device shown and described herein, user authentication can be provided instead of authorization, in a manner where the server does not retain client information but rather maintains a sufficient amount of information to allow for client recognition. The security considerations for one or more BOPS implementations may include identity assertion, role collection, access control, auditing, and assurance. Therefore, one or more BOPS implementations heavily consider the server-side component in an end-to-end biometric solution. Regarding identity assertion, one or more BOPS implementations can provide continuous asset protection and ensure the location and feasibility of adjudication and other key features. One or more BOPS implementations can further assist in identity assertion to help confirm that named users are who they claim to be, without direct reliance on human biometrics. The standards shown and described herein include an interoperable standard that can incorporate virtually any identity assertor or a range of different assertors associated with the same named user.Implementing an IDS (e.g., via 112 client devices) can provide active monitoring to help prevent the spoofing of a set of credentials and / or to blacklist a subject or device that has been determined to have made or is attempting to make one or more malicious attempts. Furthermore, role collection is supported as a function of data confidentiality and privileged access, based, for example, on rules defined and / or enforced by a known system. For instance, to determine whether a specific access mode is permitted, a specific privilege associated with a respective role can be compared to a group classification. The structure of an object can be defined through access control, and role collection can occur at the system level or through a call between the client and the server. For example, a BOPS server might store role collection information to associate a unique user with a unique device.Access control may include the implementation of one or more modules running on a computing device that determine that a given subject (e.g., a person, device, or service (e.g., a software program)) is authorized to access and / or take actions such as reading, writing, executing, or deleting a given object. In general, access control can be discretionary or, alternatively, mandatory, which can be more granular. Discretionary access control, for example, considers access to one or more objects as a function of named users and named objects (e.g., files and programs). An allocation mechanism, for example, can be role-based and allow users and administrators to specify and control the sharing of objects by named individuals and / or defined groups of individuals. The discretionary access control mechanism provides, in one or more implementations, that objects are protected against unauthorized access at the group or individual level for one or more objects. Therefore, the granularity associated with discretionary access can vary from the individual to the group level. One or more BOPS implementations can enforce a mandatory access control policy on all subjects and objects in storage (e.g., processes, files, segments, devices) under control within a respective implementation. These subjects and objects can be assigned sensitivity labels, which can be a combination of hierarchical classification levels and non-hierarchical categories. The labels can be used in adjudication as the basis for mandatory access control decisions. For example, software running on a client device (104) causes the device to maintain labels, or a BOPS server (102) maintains data to enforce adherence to the labeling of the subject and objects. The BOPS server (102) can maintain a trusted store as a component of a BOPS implementation.As used herein, a trusted store generally refers to the storage of data in a secure manner, such that access control (DAC or MAC) ensures that the subject receives the correct object and also ensures non-repudiation and confidentiality. The following identifies the access control rules and options supported in one or more sample BOPS implementations. A subject may be granted read access to an object only if the subject's security level ranking is greater than or equal to the object's security level ranking. One or more non-hierarchical categories at the subject's security level may include all non-hierarchical categories at the object's security level. A subject may write to and / or execute an object only if the subject's security level ranking is less than or equal to the object's security level ranking, and all non-hierarchical categories at the subject's security level are included within the object's security level ranking.The identification and authentication data can be used by the BOPS 102 server device to authenticate a user's identity and to ensure that the security level and authorization of external subjects to the BOPS implementation who may be created to act on behalf of the individual user are controlled by that user's release and authorization. This application aims to enhance accountability, including as a function of one or more modules that enable auditing and verification that a security model is functioning, which is generally referred to herein as a guarantee. In the unlikely event that a computing device within a BOPS implementation is compromised, these modules prevent the compromised system from operating undetected. For example, in BOPS implementations, audit requests can be supported at the subject or object level, or at the group level, even as a function of aspect-oriented programming, as known in the art. This increases the likelihood that calls will be securely written to an audit trail. Furthermore, a RESTful web service interface and a JavaScript object notation (JSON) can provide a mechanism for reading an audit trail.An audit can be conducted on the subject of an action, the object of an action, or a group of users. For example, a group of users might be designated by a specific name (e.g., accounting) and could audit all entries in a ledger. Additionally, individuals, such as a finance director, might be provided with audit information to review the income statement. One or more JUnit test suites can be used in one or more BOPS implementations to test and monitor boundary conditions, which may include testing boundary components and conditions within a system. In one or more BOPS implementations, security provisions can be met, at least in part, as a function of APIs. The use of APIs eliminates the need to identify and / or customize BOPS implementations to fit an underlying system, such as a relational database management system, a search engine, or virtually any other architecture. The functionality provided by a respective BOPS implementation can offer a point-and-cut mechanism for adding appropriate security to production systems as well as development systems.Furthermore, the architecture of one or more BOPS implementations is language-independent, supporting, for example, REST, JSON, and SSL for the communication interface. In one or more implementations, the architecture is based on the servlet specification, open SSL, Java, JSON, REST, and a persistent store. The tools can adhere to open standards, enabling maximum interoperability for devices, as shown in Figure 1. In one or more BOPS implementations, identity assertion, role collection, multi-level access control, auditing, and assurance are provided. These can be implemented as a function of a combination of at least one specially configured client device (e.g., smartphone or mobile device), a BOPS server, and an intrusion detection system (IDS) comprising devices. In one or more implementations, a client device runs an application and uploads a one-time Secure Sockets Layer (SSL) or Transport Layer Security (TLS) bidirectional key to establish an initial secure communication session with the BOPS server.The one-time key is replaced, at least functionally, by a subject's two-way SSL / TLS key, which is generated and / or provided during an identity phase (generally referred to herein as Genesis). Genesis generally comprises an initial or early step in a process that links a set of biometric data to a specific subject. Another phase, generally referred to herein as Enrollment, includes the steps associated with registering a user and / or device in a BOPS implementation, and may include issuing a certificate for a client device, securing the client certificate, and protecting sensitive data stored on the client. In one or more BOPS implementations, an infrastructure is provided that handles data encryption and secure client-server communications. The BOPS infrastructure can support the Genesis and Enrollment decoupling processes and coordinate these processes with various Enrollment elements. These dependencies, which can identify a BOPS 102 server infrastructure, include: BOPS DNS, BOPS TrustStore, BOPS KeyStore, and the BOPS key negotiation protocol. Regarding certificate management, a DNS entry for the BOPS server's 102 hostname can be configured to hold a key in the keystore for one-way SSL. The TrustStore in one or more BOPS configurations is a two-way SSL mechanism that defines the certificate authority to sign all relevant certificates.At the transport layer, a BOPS identity can be established through a bidirectional certificate and a keystore by performing a handshake. The keystore supports transport layer security through a key stored within it. This keystore can use a well-defined and recognized certificate authority, such as Verisign, GoDaddy, or another authority, which can be used to identify a host for SSL / TLS encryption. As described herein, one or more BOPS implementations utilize a one-time password (OTP) process to require a client device to request a password that unlocks the bidirectional SSL certificate.This can be done by the client device 104 and the server 102 by synchronizing an OTP to return the key to unlock the certificate after a bidirectional SSL session is initiated. In one or more implementations, various Key Enrollment elements support client certificate authentication when client devices 104 send requests to the BOPS server 102. A token, for example, can be configured as an identifier that links a profile on the server to an identity, such as a data element function, for example, Common Name. The OTP process includes one or more mechanisms for requesting the password from the server that unlocks the bidirectional SSL certificate (x.509). The password can be changed for each use by means of a predefined algorithm coordinated between the computing device of the MA / a / ¿U¿¿ / UUUOOO server 102 and client computing device 104, and the channel used for the OTP is preferably different from the channel used for the individual certificate. For example, a push notification can send a password used to unlock the individual certificate. A different certificate can be used to obtain the password to unlock the individual certificate. In any case, the certificate unlocking mechanism cannot involve storing that password on the client device 104. In one example, an application uses a predetermined certificate (for example, one previously uploaded) for Genesis and Enrollment. Subsequent processing can use the predetermined certificate with the current OTP. The result (for example, an HTTP response) can include the password to unlock the certificate. The OTP would then be forwarded to the client and server. In one or more BOPS implementations, a tupia of 5 is a high-entropy value used to prevent replay attacks. These values ​​can appear in Enrollment and may become part of future communications between the client device (104) and the server (102). The interaction of the client application with the server in a BOPS implementation can be considered a three-step process, and at least two possible variations can follow the initial step. In this case, this document describes a client application architecture with the BOPS server with reference to three components: the client application running on a client device (104), an application running on the BOPS server (102), and a server-side application (referred to as the Application Server in the diagrams). In the examples illustrated in Figures 2 through 6, the server-side application does not necessarily run through the BOPS server (102), since the SSL / TLS connection can terminate on the application server. Furthermore, a deployment of the respective BOPS implementation does not require the application to trust the BOPS system with unencrypted content.With reference to Figure 2, during the Genesis process, client device 104 makes a call to BOPS server 102 and authenticates the user-side and client-side application software. Subsequently, client device 104 receives a certificate assigned by BOPS server 102 that is specific to the client identity of a particular application. During the next step (Figure 3), the client device or application directly calls the application server. The SSL / TLS connection between the client and server portions of the application begins and ends at these points. The content exchange is preferably not visible outside the application to the BOPS 102 server or to any untrusted entities within that application. During the client session (Figure 4), the application server calls the BOPS 102 server to obtain the identification details and confirm that the certificate has not been previously revoked. In a second variation (partially represented in Figure 5), the Genesis steps (including those outlined in Figures 2 and 3) can be the same. From then on, the BOPS server 102 contacts the application server component 106 to notify it that a new client 104 has been registered and assigned. The flow of the second variation differs from the flow of the first variation in at least two ways: the identity details are different, and the revocation verification is obtained within the client session (Figure 6). In the third step, when the client device 104 directly calls the application server 106, the application server 106 calls the BOPS server 102 to confirm that the certificate has not been previously revoked. The features shown and described herein in relation to the sample BOPS implementations can be used by, or in connection with, the access control modules provided herein, or can be added to an identity assertion element of an existing structure. Therefore, implementing BOPS enables reliable processing by performing minimal actions in the production environment and thus often eliminates the need for an application software change. Figure 7A illustrates the devices and steps associated with a sample Enrollment process and the confidentiality of related data, according to one or more BOPS implementations. Bidirectional SSL / TLS, which in this application is built on top of unidirectional SSL / TLS, provides communication from the client device 104. The initial communication (for example, Genesis) can define the origin of the client's identity and can pass a BOPS-compliant bidirectional certificate that the client device 104 can use for subsequent communications, in conjunction with session-oriented identity assertion. In one or more implementations, the client application can have a preloaded bidirectional SSL / TLS key that enables subsequent Genesis operations. According to one or more implementations, a BOPS server 102 receives one-way SSL / TLS communication with a two-way SSL / TLS identity from a client device 104. Communication takes place over both one-way and two-way SSL / TLS. In one or more implementations, server 102 uses a data store to retrieve information from the trusted identity and to collect the roles to process on behalf of that identity. Furthermore, auditing maximizes appropriate mechanisms for continuous verification and validation of trusted access. Assurance can be presented as a function of simplifying and documenting a multi-level access control mechanism.In one or more BOPS implementations, an administration console (hereafter referred to as the "administration console") is provided in a graphical user interface after completing a registration process. This console allows for the dynamic modification of users, groups, and roles, and is described in more detail herein. An example of an administration console is illustrated in Figure 7B. With reference to Figure 7A, a token request (RESTful) is transmitted from a client device 104 (1) and received from the BOPS server 102 and verified (2). A DNS entry for the hostname of the BOPS server 102 can be configured to have a key in the keystore (3), and a request is formatted (4A), and m token responses are transmitted to the client device 104 via bidirectional SSL / TLS (4B). A token c (e.g., a 5-tuple and a timestamp) is then transmitted from the client device 104 (5), which is verified, including as a function of an m timestamp in the request (6, 7). From then on, the missing 5-tuple (8) is determined against a trust store and a request is formatted (9) and a SHA512 token is transmitted to the client device 104 (10). Continuing with reference to Figure 7A, a registration request containing the SHA512 token is transmitted from the client device 104 (11) and received for verification by the BOPS server 102 (12). The client's signature request is then processed to unlock the certificate (13), including calculating a one-time password, verifying a token count against a key store (14), and sending the client's certificate password to an external notification service (15). Furthermore, the verification step in 12 branches out to steps associated with analysis, including determining device information (16), profile information (17), and biometrics (as shown and described herein) (18). In addition, the client device certificate password is transmitted back to client device 104 (19), along with a formatted request (2) and a SHA512 token (21). A custom security request, including the SHA512 token, is then transmitted from client device 104 (22) and verified by BOPS server 102 (23). A request (24) is formatted, and a custom security response (including a SHA512 token) is transmitted to client device 104 (25). In one or more BOPS implementations, an active intrusion detection system is provided, including through 112 devices. This active intrusion detection system is effective in preventing brute-force attacks, denial-of-service attacks (e.g., distributed or single-site denial-of-service), and other attacks. A custom rule can be defined and applied to identify and track attempts to spoof bidirectional SSL / TLS certificates, replay sessions, forged packets, or employ a variety of circumvention techniques in an effort to compromise a BOPS 102 server device. In one or more BOPS implementations, visual cryptography is used to encrypt an initial biometric vector (IBV). This technique offers the advantage of rapid IBV reconstruction, such as through the use of an XOR operation on a specific device performing a biometric match. For example, techniques developed by Moni Naor and Adi Shamir, which provide a secret exchange scheme, can be used. In one example operation, a vector is divided into N shared resources, and the reconstruction of the initial vector requires all parts of the N shared resources. The respective devices include a BOPS server (102) and a mobile client application (104), and the enrolled vector can be divided into two shared resource parts, one of which is stored in a BOPS repository accessible via the BOPS server (102) and the other on the mobile computing device (104). In one or more implementations of this application, other forms of encryption and / or mechanisms may be used to ensure data confidentiality. For example, elliptic curve cryptography may be used instead of (or potentially in addition to) sight cryptography. During an example biometric authentication action, a newly acquired vector and both MA / a / ZUZZ / UUUOOO shared resources of an enrolled vector can be available in a single location (for example, the mobile computing device application 104 or the BOPS server 102) or in multiple locations. In either case, through the use of the enrolled vector's shared resources, the initial vector can be reconstructed in memory, thereby supporting the authentication that occurs against it. Figure 8 illustrates an overview, including data access and exchange, in relation to an enrollment process. With respect to the BOPS server 102, identification is provided as a function of a subject's account and device. The subject's account and device are part of the given subject's profile information. The profile information is stored in a clustered data store. For matching, the IBV is taken from shared resources, reconstructed, and decrypted.If the matching algorithm is not a Euclidean matchable, the match occurs as plaintext, otherwise the match occurs in the cipher domain. In an alternative implementation, homomorphic encryption is used, which allows calculations to be performed on the ciphertext, thus generating an encrypted result. Matching operations can be performed in an encrypted space, thereby increasing privacy and security. For example, matching can occur in the encrypted space through the use of one-way encryption, thus providing a high level of privacy and effectively preventing the extraction of the original plaintext IBV. In one or more implementations, an algorithm performs one-way encryption in such a way that it has two parts: one for the client and one for the server. If the matching uses a Euclidean distance (for example, a Hamming distance), as is known in the art, then the matching occurs in the ciphertext. Alternatively, if the matching does not use a Hamming distance, then the matching occurs in the plaintext space, as described herein. In one or more implementations, a random one-time keyboard (ROTP) is used to perform one-way encryption, allowing matching to be done in the ciphertext. Alternatively, sight cryptography is used for reversible encryption in the case of plaintext matching. For example, if a Hamming distance is not available, sight cryptography is used to return to plaintext for matching in memory. Preferably, encryption and decryption use one of two encryption algorithms: 1. Bitmask or 2. Matrix Transform. Ideally, all matching algorithms will have a Hamming distance, and therefore the server will never have a plaintext IBV. The following is an example algorithm for iris recognition that is performed as a function of calculating the Hamming distance between two binary vectors. In the example algorithm, the matching can be performed directly on the encrypted halves of the biometric data without converting them to plaintext, as follows (Λ denotes the bitwise XOR operation): The server stores: Register vectorΛnoise. The phone sends: Check vectorL the same noise. The comparison is carried out on the server: (Enroll vectorΛnoise)Λ(Check vectorΛsame noise). XOR is commutative and associative, and therefore this can be rearranged to: (Enter vector → Check vector) → (noise → same noise). XOR is self-inverse, and therefore (noiseL the same noise) = I, where I is the identity element for XOR, which is 0. Therefore, the expression simplifies to: (Enter vector∧Verify vector)∧I = (Enter vector∧Verify vector). The Hamming distance between A and B is a function of A ∩ B. Therefore, the Hamming distance between the vectors with noise is identical to the Hamming distance between the original vectors. In an example implementation, the following occurs during registration: a) . Inscription vector: 00110011 b) . Random sequence (first half of the vector): storage on the server 01010101 c) . Second half of the vector (calculated): storage on the phone 01100110 During verification: e) . Verification vector: (note that only the last bit changed between register and verify because this is a good match). 00110010 Second half of the vector: stored on the phone 01100110 f) Calculate the approximation to the first half of the vector (from e and c): 01010100 In the coincidence: g) . Send this verification of the 1st half (f) to the server. h) . The server now has: Inscription vector, 1 half b): 01010101 Verification vector, 1s half f): 01010100 Indicate all bits that have changed between byf with a 1: 00000001 The system may say that only the last bit changed between registering and verifying, which represents a good match, but note the way the server was only dealing with the mixed data and that the actual vector is not known on the server, but can only calculate the difference in the vectors. In an alternative implementation, facial recognition is performed by calculating the Euclidean distance between template vectors, where the face cannot be reverse-engineered from the vector. When two face images are matched, for example, using a neural network, each face is first converted into a 128-byte floating-point vector. The representation of this floating-point vector is arbitrary, and the original face cannot be reverse-engineered. To compare the faces, the Euclidean distance between the two vectors is calculated. Two faces of the same person should have similar vectors, and faces of different people should be further apart in Euclidean space. A verification vector can be calculated on the mobile device and transmitted to a remote server to be matched against a stored enrollment vector.Accordingly, an original biometric (e.g., face) will never leave the user's device, and all matches can be calculated on the server. In yet another implementation, fingerprint recognition is performed by calculating the Euclidean distance between template vectors, where reverse engineering of the fingerprints from the vector is not possible. Similarly, as described in the preceding paragraphs, a neural network can be applied for fingerprint matching. In such a case, the fingerprint can be converted into a vector on the device and transmitted, thus eliminating a way to reconstruct the original fingerprint image from the network's output vector. In one or more implementations, an encryption key is randomly generated on the device, which is used to obfuscate the output vector from the neural network. For example, the encrypted biometric vector = encryption matrix χ plaintext biometric vector. In such a case, the transformation of the encryption matrix has the special property that Euclidean distances are preserved, so the matrix must be a rigid transformation. In such cases, the biometric vector does not leave the device in an unencrypted format, and the server compares two encrypted biometrics and calculates the Euclidean distance without knowing the plaintext. When the user wants to verify from a new device, they can transfer the encrypted data to the new device, for example, via a QR code. This requires that the old device be available.If the old device is lost or otherwise unavailable, the user re-enrolls, as shown and described herein. In accordance with the above, enhanced privacy is provided through a biometric vector that is fragmented and stored encrypted across all devices. No part of the biometric vector exists on the server in plaintext form, either on disk or in memory. Furthermore, this application provides enhanced analytics, as users wishing to conduct what-if analysis of successful and failed authentications can do so through an administrative interface that supports facets, searches, analysis, and similar functions. Figure 9 illustrates the components of a sample Security 900 architecture according to one or more BOPS implementations. As shown in Figure 9, a cluster can be configured. The BOPS 902 security protocol IVIA / a / ZUZZ / UUUOOO is used to run BOPS instances on virtual private networks (VPNs). Key attributes of a certificate authority, such as the BOPS KeyStore and BOPS TrustStore, can be located within the BOPS instances. BOPS instances can also contain data associated with, and / or representing, DNS, the OTP library, notification service keys, enterprise adapters, and BOPS configuration properties. The 904 load balancer cluster can include one or more devices that ensure the reliability and availability of BOPS services and the distributed workload. A configured BOPS 904 load balancer can operate to maximize performance, minimize response time, and prevent overloading of any single resource within the BOPS 900 architecture. Continuing with reference to Figure 9, a persistence cluster 906 can include one or more database security groups and can be configured for BOPS autoscaling of data clusters. Since authentication services handle large data objects and large datasets, a large data warehouse, such as NoSQL, and one or more horizontal data partitions (shards) can be employed to improve performance by simultaneously reading from the shards and merging the results. The database security architecture 900 implements a BOPS architecture and avoids centralized storage of sensitive data in a single location. Also illustrated in Figure 9 is the monitoring cluster 908, which can include IDS 112 appliances. Figures 10A and 10B illustrate the devices and steps associated with the respective and alternative enrollment processes 1000 and 1010, respectively, according to one or more BOPS implementations. The implementations shown in Figures 10A and 10B provide the mechanisms for storing the encrypted biometric data associated with the account or device, for storing information about all changes to the biometric data, for loading and using the authentication services and their corresponding biometric libraries (e.g., FACE, 4F, IRIS), and for providing the API operations to support new flows (e.g., enrollment and authentication). In the implementation shown in Figure 10A, a software application (MCA) running on a mobile computing device 104 provides the acquisition of an initial biometric vector (IBV), to carry out a cryptographic split operation during the enrollment process and the distribution of this process for a lower CPU load on one side of the server, to carry out the enrollment request (registration) with the BOPS server 102 and to carry out a cryptographic matching operation, when the method for the authentication flow is configured to take place on the client side 104.The BOPS 102 server can be configured to store user identity data along with the shared vector, for example, in the BOPS 1002 Big Data store during an enrollment process. Furthermore, the BOPS 102 server can manage the authentication flow and integrate the communication component of the authentication service (1004). An authentication service (1006) can dynamically load one or more authentication algorithms and biometric engine libraries, provide version control support for authentication engines, standardize communication between a BOPS 102 server and one or more biometric engines, and standardize communication between a BOPS 102 server and the authentication engines.An authentication service acts as a wrapper for a biometric service when authentication is performed. As explained in this document, one or more mechanisms are provided for pluggable authentication services and their corresponding biometric engines. Accordingly, BOPS implementations can be configurable (for example, through the localization of authentication services and biometric libraries) and can automatically load available services and register with the system. As a result, a list of enunciation services is available at the system level, for example: 4F engine; FACE engine; IRIS engine; VOICE engine. A list of authenticators includes a FIDO authenticator or a BOPS authenticator. This application provides enhancements to biometric integration authentication services by supporting the following features. One or more mechanisms may be provided for storing encrypted biometric data in an account or on a device accessible to the BOPS 102 server. Additionally, a mechanism may be provided for storing information representing changes to the biometric data.In addition, a generic mechanism may be provided for accessing and using the authentication services that include (for example, in connection with biometric face, four-finger, and iris authentication, as shown and described in United States Patent Application Serial Number 14 / 201,462 commonly assigned, in United States Patent Application Serial Number 14 / 201,499, in United States Patent Application Serial Number 14 / 988,833, and in United States Patent Application Serial Number 14 / 819,639. In one or more implementations of this application, a mobile computing device 104 acquires an enrollment vector and performs a cryptographic split operation during an enrollment process. This provides improved computing functionality by distributing the process and reducing the CPU load on the server side. Additionally, the mobile device 104 can make an enrollment (registration) request to a BOPS server 102 and perform a cryptographic matching operation when a Biometric Validation step from the authentication flow is configured to take place on the mobile device. In one or more implementations of this application, the BOPS 102 server stores user identity information along with at least a portion of a shared vector, for example, in an Apache Solr repository during the enrollment process. Furthermore, the BOPS 102 server can be configured to manage authentication information and process flow, and to integrate at least one communication component of the biometric service. Other components provided in an architecture according to this request may include one or more authentication services and one or more biometric engines. The authentication services may be configured to dynamically load one or more libraries that are configured to support version control of one or more authentication services, to standardize communication between the BOPS 102 server and the authentication services, and to provide one or more deployment scenarios, such as web application machines where one or more BOPS instances are either a standalone or self-scaling cloud. In one or more implementations, the biometric engines are configured to understand unmanaged biometric libraries that are the object of an interface and are defined and implemented, for each respective library, to connect to the system implemented by BOPS. The biometric engines preferably offer a Load method to load an engine if necessary, an Unload method to unload an engine to free up resources (e.g., memory, temporary files), a Get State method to provide status information (e.g., INITFAILED, OK, ERROR, OUTOFMEMORY), a Split method to encrypt a vector acquired during enrollment, a Match method to authenticate a vector, for example, based on shared parts of an initial vector, an Activate / Register method, and an engine description.The description may include, for example, a biometric type identifier, a name and description, an engine version, and a biometric format. Using this information, one or more processes associated with this request can automatically load and register a specific biometric engine. In one or more implementations, a mechanism for pluggable authentication services is supported, enabling the system to be configurable (authentication service location) and to automatically load available libraries and register with the system. Each biometric library, called by the authentication service, can provide information such as a constant string (biometric type), a respective version, a name, and a description to describe itself. Furthermore, information such as the pair (Biometric Type, Biometric Version) can identify a unique biometric engine. The example authentication services and their corresponding lower-level biometric engines can be listed and made available at the system level, including, for example, 4F, FACE, IRIS, and VOICE, as shown and described in United States Patent Application Serial Number 14 / 201,462 commonly assigned, in United States Patent Application Serial Number 14 / 201,499, in United States Patent Application Serial Number 14 / 988,833, and in United States Patent Application Serial Number 14 / 819,639. As noted in this document, in one or more BOPS implementations, the Genesis and Enrollment processes are effectively decoupled, allowing a subject's identity to be determined without directly requiring a BOPS 102 server to access a biometric vector, certificate, or other sensitive information that would otherwise be needed for automated processing. Accordingly, a BOPS solution can be interpreted as open and can allow virtually any customization in Genesis and Enrollment. For example, Genesis might include the use of a username and password to access Active Directory, a validation email or text message, or an organization official to physically verify identity. Pre-registration of a user account, for example, which can be implemented in batches, can be based on business requirements.Furthermore, a Genesis process can form a complete dependency of risk management and can also determine subsequent processing. During an example post-Genesis process, a user enrolls their biometric data, which may include a unique client certificate issued for a specific enrolled device. Additionally, a one-time password (e.g., a seed) can be established between a client device (104) and a server device (102), and an additional seed value can be used for replay attack prevention. It is recognized in this case that a single user can have many devices and / or a single device can have many users (i.e., a single device can have many biometric data points). Therefore, a form of many-to-many relationship can occur as a function of separating the Genesis and Enrollment processes. Accordingly, a subject identified through Genesis can be enrolled multiple times with multiple biometric data points. In one or more BOPS implementations, the enrollment process uses a bidirectional Secure Sockets Layer / Transport Layer Security (SSL / TLS) certificate, which can be generated on the server. This generation can occur after the Genesis process, thus ensuring that the certificate is appropriate for the well-defined subject. Furthermore, one or more BOPS implementations can have multiple provisioning levels, providing flexibility for varying levels of security. For example, a high Genesis level might involve a user being physically validated in front of someone, such as an official. A low level, on the other hand, might simply involve defining a username and password along with a validation email that the user receives. Multiple Genesis levels and verification processes can be implemented based on one or more business decisions that may be unique or specific to one or more organizations. Additionally, subsequent processing can change depending on the respective Genesis level. For example, a system might allow a $1,000,000 transfer under a high Genesis level, but only a $100 transfer under a lower Genesis level. Figure 11 is a block diagram illustrating the possible requirements and 1100 examples associated with different levels of Genesis, according to this application. As additional requirements are needed in the verification processes, the respective security levels may increase accordingly. In the example levels in Figure 11, the first and second levels may be interchanged based on organizational considerations. For example, if an objective is to verify and grant Wi-Fi access to business visitors, then the verification can be sent via a mobile device and is considered herein as a low verification level. During an enrollment phase, a mobile application running, for example, on a mobile computing device 104, enrolls biometric data based on its integrated capabilities. For instance, a mobile application designed for a specific integration and requiring predetermined biometrics might have those modules specifically coded into the application. One or more BOPS implementations address the speed of biometric authentication transactions and resolve the problem of a virtualized threat on a mobile device. An example of such a threat is an intruder decompiling code into a virtualized image copied from a mobile device, using this source code to disrupt authentication calls, and attempting to gain control of a server that authenticates and grants permissions. To mitigate these risks, the process in a BOPS implementation encrypts the Initial Biometric Value (IBV) without the encryption key. Half of the IBV is then stored on the client device 104, and the other half is stored on, or otherwise accessible through, the server 102. Biometric matching can occur on the server 102. Figure 12 illustrates an example of the information flow 1200 associated with an Initial Biometric Value (IBV) during the enrollment and authentication processes. In the example flow illustrated in Figure 12, the IBV is captured and split during enrollment, and a portion (e.g., half) of the IBV is stored on the client device 104.A portion (for example, half or 1 / 2) of the IBV is transmitted in an enrollment request to the BOPS 102 server, and the portion is stored, for example, in a data store accessible by means of the BOPS 102 server. From then on, confirmation of enrollment is transmitted by the BOPS 102 server. Continuing with reference to Figure 12, a current biometric vector (CBV) is captured during a subsequent biometric authentication process and sent in conjunction with an authentication request (Aut) to the BOPS 102 server, including a remaining portion (2 / 2). The BOPS 102 server is configured to combine the received portion of the IBV in the authentication request with the stored portion of the IBV for decryption. The received CBV is compared to the full plaintext IBV, and a number (e.g., a floating-point number) is returned to the client 104 computing device based on the result of the comparison. If there is a match, the user can be logged in as authenticated. Furthermore, the results of the authentication process can be displayed on the client 104 computing device. Therefore, as illustrated in the steps shown in Figure 12 and described herein, a BOPS implementation in accordance with this application addresses the speed of a biometric authentication transaction and resolves the problems associated with a virtualized threat on a client device. This threat can occur, for example, after an intruder decompiles the software on a virtual image copied from, for example, a mobile device, uses the source code to disrupt authentication calls, and attempts to gain control of the server that authenticates and grants permissions. To mitigate these risks, features associated with a BOPS implementation can operate to encrypt the IBV without an encryption key, storing one portion (e.g., half) of the IBV on the client device and another portion (e.g., the other half) on the server or a device accessible in this way. Biometric matching can occur on the server. In this way, a stolen device cannot bypass authentication, at least in part because a compromised device or server does not provide information useful to an attacker. According to one or more implementations, the following establishes a processing agreement for biometric authentication in one or more BOPS implementations. A biometric vector is divided between at least the client and the server, and the authentication approach is biometric-agnostic. For example, with regard to facial recognition, the size of the initial biometric vector might be approximately 20 KB, which could be minimized by up / down on an HTTP request and HTTP response, and is therefore acceptable. The division algorithm for an IBV with regard to facial recognition might be as follows: bit zero represents white, and bit one represents black. Accordingly, a BOPS implementation can correspond to visual cryptography (VC).As noted in this document, this application is compatible with virtually any biometric and provides a mechanism for capturing the IBV and encrypting it with the VC. With the VC, the match occurs in plaintext. Alternatively, with Random, the match occurs in the encrypted domain. With specific reference to Figure 12, a user operating the client computing device 104 proceeds with biometric enrollment (1) and captures an initial biometric vector (IBV) (2). In step (3), the IBV is encrypted and split, with 2 / 2 of the IBV stored locally on or with the client computing device 104 (4), and an enrollment request containing 1 / 2 of the IBV sent to the BOPS server 102 via a transport layer (using bidirectional SSL / TLS) (5). The remaining 1 / 2 of the IBV is stored by the BOPS server 102, as in the BOPS Big Data (6), and an enrollment confirmation is transmitted from the BOPS server 102 back to the client computing device 104 (7). Continuing with reference to Figure 12, after enrollment, biometric authentication occurs on the client's computing device 104 (8), and a current biometric vector (9) is captured. An authentication request is then sent through the transport layer (10), received by the BOPS server 102, combined with the 2 / 2 IBV, and used for decryption (11). The CBV is then compared to the plaintext IBV (12), and a floating-point number is transmitted to the client 104 (14), with the results displayed (15). Turning now to Figure 13, an example of Visual Cryptography (VC) 1300 is shown, implemented in connection with this application. VC provides good synergy with encryption, IBV splitting, and IBV reconstruction without requiring key management. In the visual cryptography example shown in Figure 13, black can be equal to 1 and white can be equal to 0. In the example, the IBV is equal to 00100110. An XOR reconstruction is usable because the solution is Boolean. The encryption process of the original biometric vectors can occur through the use of visual cryptography, and the results can be two vectors annotated as leaves, containing only white noise. Mobile storage (e.g., client device 104) contains one of the leaves, and server device 102 contains or accesses the other.The verification process combines the two sheets through the use of a simple Boolean operation that results in the original biometric vector being completely reconstructed. The following is an example of the reconstruction of an IBV in relation to an XOR operation in Table 1. Original 0 0 1 0 0 1 1 0 Shared 1 01 10 10 01 10 10 01 01 Shared 2 01 10 01 01 10 01 10 01 OR - rebuild 01 10 11 01 10 11 11 01 XOR - rebuild 00 00 11 00 00 11 11 00 Table 1 With reference to Table 1 and in relation to an example of a BOPS implementation, the encryption process of the original biometric vectors can occur through the use of visual cryptography, and the results of this encryption are two vectors annotated as leaves containing only white noise. As indicated herein, the storage associated with client device 104 contains one of the leaves, and the storage associated with server device 102 contains the other. The verification process combines the two leaves through the use of a simple Boolean operation, resulting in the complete reconstruction of the original biometric vector. Figure 14 illustrates an example overlay of two shared resources (2, 2) in the Visual Cryptography Scheme (VCS), where each bit is encrypted in shared resources relative to an example BOPS implementation. In the example shown in Figure 14, the choice of shared resources for a zero bit and a one bit is a random process. When encoding the zero or one bit, a value is taken from the table for one shared resource and the adjacent value from the table for the other shared resource. At the end of the process, neither shared resource provides any clue about the original bit. Overlaying the two shared resources (by using OR or XOR) determines the value of the original bit. Continuing with reference to the example shown in Figure 14, an overlay of the two shared resources (2, 2) is shown in a Visual Cryptography Scheme (VCS), where each bit is encrypted in shared resources. Note that the choice of shared resources for a zero and a one bit can be implemented in a random process. When encoding a zero or a one bit, a value is taken from a table (for example, from Table 1) for one shared resource and the adjacent value from the table for the other shared resource. At the end of the process, neither shared resource provides any clue about the original bit. From then on, the overlay of the two shared resources, for example, through the use of OR or XOR, determines the value of the original bit. This is an example of a (2, 2) VCS.The VCS can be extended to more than two shared resources by changing the probability of the random process. Changing the probability of the random process from 0.5 to 0.25 results in the shared resources having 4 bits instead of the two bits present in the 0.5 example. Furthermore, changing the probability of the random process to 0.125 results in an 8-bit encryption for each input bit. Regarding match detection, one or more modules in a sample BOPS implementation employ multiple initial biometric vectors. There are then two calls to RESTful web services communicating over SSL / TLS, one for each biometric. One call might include halves of the initial biometric vectors, along with the current biometric in an authentication session, and might return a floating-point value representing the match strength. Another call might offer one half of each initial biometric vector at a time, along with the current biometric, and might also return a floating-point value representing the match strength. For the second call, there could be multiple consecutive calls—for example, one initial biometric vector at a time—to determine a match. Size calculations by a match agreement in relation to an example BOPS implementation, may be as follows: 20 kb per face vector, 5 frames per second; for 10 seconds = 50 vectors; 50 x 20 kb = 1000 kb. The following describes an example of the matching logistics in relation to the implementation identified in the preceding paragraphs. The 1,000 KB are sent to the server for matching. If there is no match, the next 100 KB are sent, and so on, until a floating-point value is determined. In one or more BOPS implementations, a minimum threshold is defined, and the floating-point value is at least within this minimum threshold. According to an example matching algorithm, the current frame requires 200 milliseconds plus an up / down time of 125 milliseconds for the server. Therefore, the frame transmission brings the transaction speed to 325 milliseconds per frame, plus the matching time. When the matching time is capped at 100 milliseconds, the frame transmission time is approximately 425 milliseconds.If this fails, a batch of frames (for example, five at a time) can be transmitted and a match can be attempted again. Ideally, the match takes less than one second, although in certain less favorable cases, the match could take longer, such as several seconds. As shown and described herein, the agnostic and flexible nature of the authenticator and biometric in this application allows organizations to define a respective authenticator and biometric that can be used for authentication and that can be defined as a predetermined biometric. In the absence of a biometric specification as part of a subsequent transaction, the predetermined biometric can be specified through one or more user interfaces, such as at the organizational level, the group user level, or the transaction level. In one or more implementations, an administration console can be configured in a graphical user interface and made accessible to the respective authorized users. The administration console can include graphical controls that, when selected, result in the configuration of a predetermined biometric type. For example, an organization, ACME Plumbing, specifies that for certain access, face authentication will be used as the predetermined biometric for all ACME employees. Additionally, ACME Plumbing specifies that in other contexts, four fingers will be used as the biometric for all customers, and further specifies that in still other contexts, both four fingers and face authentication will be used for all employee transactions exceeding $10,000. These options are presented in the administration console for configuration by an ACME Plumbing administrator.Therefore, this application provides a flexible and dynamic application of one or more biometrics. Regarding authentication, a plurality of information sources can be used for biometrics in a specific organizational configuration, such as a condition engine, a member profile, and a member definition. The condition engine can be based on dynamic rules defined in the system. For example, any transaction exceeding $1,000 requires at least two forms of biometric verification. The member profile defines user roles and their corresponding privileges. For example, the Information Security / First Responders member profile might require authentication every 10 minutes or after another condition, such as every transaction confirmation. The member definition can define a predetermined authentication process at the organizational or integration level.For example, if there are four types of biometrics available in the system—4F, FACE, IRIS—and for a specific BOPS / Enterprise implementation, the predetermined biometric is FACE, then facial authentication is available as a predetermined value and can be provided as such, for example, on a dashboard provided through a graphical user interface and referred to herein as a BOPS administration dashboard. Furthermore, the respective conditions, such as those described above, can indicate priorities. For example, the member definition could be considered the lowest priority, and the engine condition the highest. The highest priority then becomes the authentication method. The following are example steps associated with an enrollment process according to this application. A mobile computing device 104, configured with a mobile client application, acquires a biometric vector, performs encryption, and then makes a call to the enrollment API. Specifically, after acquiring a biometric, the enrollment call to a BOPS server 102 includes half of an IBV, which is stored for access by the server 102. This enrollment process can be used to initiate a BOPS implementation within an organization. Although many of the descriptions and figures shown here depict a BOPS implementation appearing as a cluster, BOPS can be configured as a business component.Before a BOPS administrator (BOPS admin) configures an environment, an organization registers to obtain a respective API key from a BOPS 102 server. Individual developers can, in various deployments, request the API key as well. Once the registration process is complete, an original site administrator (original site admin) can create additional site administrators (site admins). Registration information, including that associated with multiple site administrators, can be linked to a respective API key that is associated with an organization. In one or more implementations, the API registration can belong to two domains: the registered original site administrator; and the issued API key, which can be based on the registration information, the organization, and the use case. After the initiation of a request is agreed upon, the registration process is completed. A BOPS administrator then creates an original site administrator for an organization, and the original site administrator can create a site administrator (see, for example, the role hierarchy diagram shown in Figure 15). Before a development process using the BOPS service, a developer typically registers, for example, by using the options in a BOPS administration console. Once an application name is provided and a question-based authentication mechanism is used to identify the developer, a new account can be set up and an API key created, which would be identified with the application name and associated with the application. In one or more BOPS implementations, communication between an application running on a client device (104) and the BOPS server (102) is established over bidirectional SSL / TLS. Genesis processes establish this connection and specify how users are identified on the BOPS server (102), enabling the server (102) to generate a private key for establishing bidirectional SSL / TLS communication. The provision of secret questions is an axiomatic mechanism for user identification, allowing the respective parties (e.g., providers) to provide a set of questions that uniquely describe an individual during the Genesis phase. The client application operating on the user's computing device 104 is responsible for providing a unique identifier (ID) that identifies the end user's device 104. The application can use device 104 and its associated API to notify the BOPS server 102 about the link between the user and the user's device 104. A 5-tuple is one such mechanism that can be used to identify devices 104. In one or more BOPS implementations, the respective RESTful calls and / or usable behavior for a system to defeat attacks and attack vectors are specified. Additionally, a request format is specified to protect real-time data from known and unknown attacks, and this may be present in an IDS (through, for example, 112 devices). For instance, replay mitigation can be used in a one-time cryptographic token to validate access. In such a case, the IDS acts as a third layer, verifying that the client (104) and server (102) know each other, thereby ensuring that server (102) is fully protected. MA / a / ¿U¿¿ / UUUUOOO the application layer. Figure 16 is a 1600 block diagram illustrating the devices and transmission flow related to replay prevention. As shown in Figure 16, one-time cryptographic tokens validate access and protect server 102 at the application layer from ISO Layer 7 cyberattacks, including replay, distributed denial-of-service (DDoS), and other attacks. The combination of the token and the IDS is useful for detecting ISO Layer 7 cyberattacks, including replay, distributed denial-of-service (DDoS), and similar attacks.The token is valid for one use and is generally passed from client 104 to server 102 and then returned to BOPS by using RESTful calls. A premise in one or more BOPS implementations is that for DDoS detection, each token must be unique, and at least one algorithm used between the client and server takes into account that time can vary and that token values ​​must differ from client to client, as well as from one access to another. Figure 17 is a high-level flow illustrating the 1700 steps associated with the token algorithm according to a sample BOPS implementation. In step 1702, during the Genesis step, a web, mobile, or embedded device (client device 104) issues a RESTful call to request a token. The token is then received and embedded in an encrypted message from client 104 to server 102 (1704).Server 102 receives the token and checks the validity of the message by passing the token to the IDS (1706), which then verifies that the token is valid and ensures that the difference between the creation time and the current time falls within a specified time period of 60 seconds (1708). Figure 18 illustrates the Genesis / Registration and User / Device products in a many-to-many relationship. On the mobile client (104), the identity elements linked to each account are shown. On the server side of Figure 18, the BOPS server (102) is illustrated in relation to identity attributes, accounts, and devices, according to the relevance of each identity. To ensure data encryption and secure client-server communication with a high level of security, identity information is linked to the secure elements through which user accounts (such as Alice's or Bob's accounts shown in Figure 18) are properly authenticated based on their corresponding identities. To initiate the Genesis step, client device 104 can choose to establish a five-tupia by specifying any or all of the respective values ​​shown in Table 2 below. The IDS can determine any of the five values ​​not set by the client and can return a token to the client in a RESTful format. Client 104 and server 102 share the same five-tupia, which is then used to calculate a timestamp. This timestamp is encoded in SHA512 and compared by either the IDS or the BOPS server 102. The calculated timestamp is then rolled back to a time based on the five-tupia and is unique for each call. Accordingly, in one or more implementations, the token does not contain the timestamp itself, as all token values ​​are converted to a SHA512 sum for comparison. This allows the values ​​to change at one-minute intervals to prevent blind replayability. Furthermore, the token's minute interval can be configured to be 3 (instead of 60) to allow for a sufficiently large entropy (48,771,072) and thus prevent trial-and-error attacks. In addition, a semantic engine can be configured to allow a security administrator to create additional custom parameters for the detection and prevention of attacks that may be outside of any international standard and for the provision of more controls and balances against a wide variety of attacks. In one or more implementations, reproduction detection operates using a five-tupia. Values, such as those shown in Table 1 above, can be provided to server 102. Alternatively, server 102 can select values ​​randomly. Based on reproduction, an acceptable range of values ​​and entropy are initially determined. If no five-tupia value is specified during the Genesis step, the algorithm can use the following values. Entropy Value Year 0 to Current Year (2016) 2017 Month 0 to 11 12 Day 0 to 27 28 Hour 0 to 23 24 Minute 0 to 2 (the entropy of minutes is 3, so the value will only be the same for 3 minutes, which limits the number of simultaneous attacks) 3 Total Entropy = 2016 * 12 * 28 * 24 * 3 = 48,771,072 Table 2 According to one example implementation, a backward-rotating algorithm is executed. If a given month is less than or equal to the current month, then the year remains the same. Alternatively, if the given month is greater than the current month, then the year rotates backward. These two cases illustrate the algorithm. Example from Genesis 1 Example from Genesis 2 GMT = 2016-08-10 15:30 Genesis Value Year 5 2011 Month 11 11 Day 4 8 Hour 6 12 Minute 2 28 GMT = 2016-08-10 15:30 Genesis Value Year 5 2015 Month 4 4 Day 4 8 Hour 6 12 Minute 2 28 Table 3 Because the current month in example 1 is the 8th (August) and the Genesis value for the month is 11, and 11 > 8, we calculate the year down by an interval of 5, and the year becomes 2011. The remaining values ​​are multiples of Genesis that are less than the actual date value. In relation to the second example using the same current date and time, the current month is the 8th (August) and the Genesis value for the month is 4, and 4 <= 8. The year is reduced to an interval of 5 which is equivalent to 2015. Therefore, the year becomes 2015 and the remaining values ​​are multiples of Genesis that are less than the actual date value. In one or more BOPS implementations, various levels of data privacy can be provided, each potentially including encrypted biometric information to prevent anyone from resetting or compromising it. One privacy level might define that all non-biometric data is stored (passivated) in plain text. This simplifies reporting and analysis of usage patterns and authentication logs and can include other factors such as non-repudiation, location, date, and faceted search. For example, a series of failed authentication attempts in Cleveland during June 2016 can be viewed with relative ease, and information about the individuals and devices involved can be provided. This first level of privacy can be achieved through sophisticated tools that operate on the passivated plain text data.A higher level of privacy might define that all non-biometric data is stored in an encrypted format, but does not require a separate decryption key for each client. Therefore, client 104 devices can be configured to use the same decryption key, which is considered more secure than the first level of privacy described above because an insider may not have access to, or most likely would not have access to, the decryption key. However, an even higher level of privacy might require that all non-biometric data be stored in an encrypted format and that the decryption key be unique to each identity. This provides greater privacy and separation because each user's data is encrypted with a key associated with a biometric.At the highest privacy levels, this document stipulates that user data, including, for example, personally identifiable information (PHI), will always be encrypted on client devices 104, except perhaps at the time of the matching process in memory. In one or more BOPS implementations, a user authenticates to authorize the transaction and then authenticates again to decrypt the user data (e.g., login credentials, files, or similar). Furthermore, data at rest (e.g., passivated data) is encrypted on both the server computing device 102 and the client device 104 at all times. Plaintext data preferably exists only in memory at the time of the matching process. In one or more BOPS implementations, open platforms are provided to allow virtually any customization for the Genesis flow. Examples of Genesis implementations might include username and password access to Active Directory, email or text message validation, or physical verification of an individual's identity, such as a driver's license, birth certificate, passport, social security number, or other suitable credential. The initial user account registration can occur in a batch process that implements business rules, and organizational policies and procedures can contribute to those rules. These business rules can be integrated with an access management platform, which organizes users into groups or directories that determine privilege levels and other attributes to suit specific role management needs. This provides flexibility, allowing developers to create member profile formulations (e.g., user profile, administrator profile, manager profile, and super administrator profile) that can be applied as input to a member definition accessed by a BOPS 102 server.The Genesis process in accordance with this application may form a total dependency of risk management and, in accordance with the foregoing, may determine further processing. Figure 19A illustrates the 1900 devices and steps associated with multiple users initiating enrollment on a single client device 104. The relationship between the user and device 104 can be many-to-many (M:M). The first enrollment steps can be aggregated (A1 Initiate Biometric Enrollment, A2 Enrollment Request (x, 509), A3 Enrollment Requirements Return, A4 Account Registration Request (Developer ID, User ID + 1 / 2 IBV), A5 Registration Return). These steps can be repeated for a second user (B1 to B5). The many-to-many relationship can occur as a function of a separation between Genesis and Enrollment. Furthermore, the subject identified through Genesis can be enrolled multiple times with multiple biometric data sets.To initiate client-server communication, users capture their biometric data on the client device, which triggers the enrollment process for a unique client certificate issued to that device. Once the security portion of the enrollment is complete, the user's biometric information is registered, concluding the enrollment process. A user can have multiple devices (clients), and a device (client) can have multiple users. A device (client) can support multiple biometric data sets. Figure 19B illustrates the devices and steps in relation to a sample user, Alice, who initiates an authentication session from a client device 104, which stores information regarding multiple user accounts. In the example shown in Figure 19B, Alice initiates the authentication session (1), and the application running on the client device 104 requests biometric authentication (2). After biometric authentication is complete (3), the application running on the client device 104 configures the device 104 to send Alice's identity attributes over TLS (4). The BOPS server 102 then processes the authentication request, taking into account the integrity of all enrollment elements, and returns the results (5). With reference to the example shown in Figure 19B, if Alice mistakenly initiates the authentication session using Bob's account, the client device 104 does not submit any request to the server because the CBV would be different from the IBV that was created during enrollment, and authentication would not be successful. Figure 19C illustrates the sample devices and steps 19-20 associated with revoking a user's account. The example shown in Figure 19C displays information associated with three users (Eve, Bob, and Alice). A user can define one or more revocation rules, for example, through an administration console configured with an administrative graphical user interface. Roles associated with an administrator (those that can authenticate biometrically in a similar manner) can be responsible for implementing the rules. In the example shown in Figure 19C, Alice's account has an active certificate, Bob's account has an expired certificate that is blocked at the Transport Security Layer, and Eve's account has been revoked by the BOPS administrator.More specifically, after Eve's certificate has been revoked via the BOPS 102 server (1), an authentication request is received from a client 104 device associated with Eve's account (2). The BOPS 102 server returns a message or other appropriate content indicating that Eve's access is blocked (3). Regarding Bob's certificate, a 90-day period is defined, after which Bob's certificate expires (TTL) (4). An authentication request is then received from the client 104 device associated with Bob's account (5), and, similarly to the Eve case, the BOPS 102 server transmits a message or other appropriate content indicating that Bob's access is blocked to the client 104 device (6).With respect to Alice's account, an additional 90-day extension period is provided (7), and an authentication request is received from the client device 104 that is associated with Alice's account (8). The BOPS server 102 returns a message or other suitable content representing the authentication results, as shown and described herein, that Alice is authenticated (9). One of the problems solved by the modules shown and described in this document is the prevention of replay attacks. In one or more implementations for DDoS detection, each token, which is typically an identifier linking the server profile to an identity in the Common Name (CN) field, is distinct. An algorithm between a client 104 and a server 102 takes into account that timings can vary, and that the values ​​must differ from one client 104 to another, as well as from one access to another. In one or more implementations, certificate distribution works as follows. An X.509 certificate is preloaded onto a client device (104), either as a function of the application software installed on the device. Before the Genesis process, the client sets a tupia value of 5 by specifying any or all of the tupias (as shown and described herein). During the enrollment process, the client makes a RESTful call to request the token from the BOPS server (102). When the token is received, it is embedded in the encrypted message from the client to the server. The server receives the token and verifies the message's validity by ensuring that the difference between the creation time and the current time is within a specified period of 60 seconds.Server 102 determines which values ​​of the 5-bit tupia are missing and returns the token to the client in a RESTful format. Client 104 and server 102 share the same 5-bit tupia value, which is then used to calculate a timestamp. This timestamp is encoded in SHA512 and compared using an IDS, for example, as a function analysis. As described in this document, the calculated timestamp is rolled back to a time based on the 5-bit tupia and is unique for each call. This application can configure a period of time for a client certificate to remain valid (Time to Live, or TTL). Revoked certificates of authenticated users can be silently replaced with new certificates. Therefore, TTL is a belt-and-braces approach, working in conjunction with IBVs and CBVs to support user authentication. Token revocation can also be conditional on a user role and other factors to meet specific business authorization needs. For example, a certificate can be blocked after 1x number of failed authentication attempts for a financial transaction, such as if conditions yy / z are not met. Figure 20A is a simplified diagram illustrating the 2000 steps associated with the initialization, verification, and confirmation of a client certificate between a client device 104 and a BOPS server 102. The steps associated with processing a client signature request (CSR) may include generating a public and private key pair on the client device 104, signing a public key and subject name (generally referred to herein as performing the Proof of Ownership) and transmitting it to the BOPS server 102. As noted herein, the client sends a registration account request using bidirectional SSL.After verifying the certificate subject name, signing the client request with the BOPS Certificate Authority (CA) private key, and generating the client certificate password using the OTP mechanism, the BOPS server 102 returns a client certificate password to the client device 104. The registered client verifies the certificate signature and creates a container (p12) to store the client private key and the signed certificate, but not the password. Ideally, passwords are never stored on client devices because the OTP mechanism generates a one-time password for each client request. Figure 20B illustrates a 2010 client certificate registration process in the example of third-party server integration and BOPS. The CSR process, for example, as shown in Figure 20A, is demonstrated extensively and begins with user enrollment. In the example shown in Figure 20B, "register user account" is used to describe the steps associated with Genesis and Enrollment, and a client certificate represents an identity attribute, while an account represents an identity component. In the example implementation shown in Figure 20B, after a user initiates the enrollment process and submits their biometric information with the account registration request to a BOPS server 102, a key pair / CSR generation is triggered on the client device 104. Once a registration profile request is received, the BOPS server 102 further sends it to an access management adapter (which may be an access management solution or platform used by a third-party company), as shown in Figure 20B depicting profile validation, and then further to a third-party server for account login verification and validation.The third-party server provides an authentication token after validating the login data and then sends the verification results back to the access management adapter. The adapter then converts the authentication results and the authentication token back to the BOPS 102 server to complete account or profile registration. The BOPS 102 server encrypts the authentication token, stores the biometric data, signs the CSR with the BOPS CA, and sends the encrypted authentication token to the client application. This represents an example implementation and integrates with an enterprise (e.g., a bank) that already has billions of accounts stored in its repository, enabling a higher level of verification as a function of biometric authentication. In one or more implementations, a Quick Response code (QR code) can be used to trigger the execution of one or more modules, which are described herein. For example, a business partner's (e.g., a bank) login page can be configured to display a QR code image containing a respective session opportunity identifier. An MCA running on a client computing device can then execute one or more modules (e.g., an authentication wizard) to scan the QR code, log the session to indicate that it is logged in, and authenticate using biometrics. IVIA / a / ¿U¿¿ / UUUOOO of the user in accordance with the teachings contained in this document. Figure 21 illustrates an example of a QR code 2100 authentication flow, in which a third-party server registers a session opportunity with a BOPS 102 server and, in response, information usable for a new authentication session can be provided by the BOPS 102 server to the third-party server, and the information can be provided (e.g., displayed) within a QR code. The third-party server can transmit one or more requests for information about the session status. A user (designated as an actor) in Figure 21 scans the QR code and registers a session with the BOPS 102 server, which can notify an external third-party server. After biometric authentication, as shown and described herein, a user session can be established, including with the third-party server. In one or more additional implementations of the BOPS servers described and detailed herein, the BOPS server is used to implement a secure user identity model that provides authority-based notification issuance and eliminates the need for third-party identity providers during authentication. The described user identity model leverages blockchain technologies to ensure the exchange of verifiable credentials without the need to entrust sensitive biometric data to third parties. For example, the multiple cryptographic shares described with reference to Figure 14 (and the potentially redundant shares of these distributed across alternative off-chain storage such as a portable hard drive, mobile device storage, IPFS, Dropbox, Google Drive, AWS, etc.) are used.These encrypted shared resources are retrieved by BOPS servers. They are provided to the BOPS server in such a way that the user's verifiable credentials are used as part of the verification system. The combination of at least two identity technologies (DID and BOPS) enables platform-agnostic, independent verification of a user's existence. In this case, by integrating biometric-based protocols into an enrollment and authentication process, users are guaranteed to link a digital identity to a physical presence in the real world. Furthermore, the user has complete control over this digital identity. The user can add more data to this digital presence, request others to add additional information, or disclose some or all of the data depending on the context.Furthermore, users can register their consent to share their data with others and facilitate such sharing. Therefore, the digital identity described herein is persistent, portable, and does not rely on any third-party authorization or validation for its usability. With particular reference to Figures 22 to 25, a secure user identification model is implemented as a process or method for securely exchanging biometric credentials through the use of the BOPS standard. Turning now to Figure 22, the Biometric Open Protocol Standard (BOPS) discussed herein is implemented in a secure, decentralized user identity model to give users control over the storage and use of their authentication and identity data. MA / a / ZUZZ / UUUUOOO As a side note, those with a basic understanding of the required technology will appreciate that the described BOPS protocol can be extended to a combination of on-device (e.g., FIDO UAF-compliant), server-side, or multi-device models that utilize remote storage and distributed authentication processes to enable user control over authentication. The above explanation is for ease of description only and is not intended to limit the additional approaches enabled by integrating the BOPS standard with one or more distributed ledger technologies. In fact, in a particular configuration, the BOPS standard allows biometric credentials to be used off-device for authentication challenges and other network-based identity verifications.However, in one or more additional implementations, the biometric data used for authentication is distributed by BOPS servers to decentralized storage locations, as well as persisting on one or more distributed ledgers through the use of blockchain technology to provide cryptographic guarantees that the biometric data is secure and tamper-resistant. As shown with continued reference to Figure 22, a 2200 user, such as an end user (or simply a user), is someone who retains control over their respective identification and / or identity data. In a non-limiting example, 2200 users include students, employees, customers, and others. However, in alternative configurations, a 2200 user may designate a holder (for example, the BOPS 102 server) to maintain control over their respective identification and / or identity data. For example, a holder could be one or more services, companies, or institutions that have been authorized by a 2200 user to participate in identification-based transactions on their behalf.In one or more implementations, permitted holders include web services, mobile applications, or native applications installed on or accessible from a user's personal devices (e.g., the client device). As used herein, holders generally refer to any entity that receives decentralized identity information, accesses stored decentralized identity information, and / or provides such decentralized identity information to resource access providers in exchange for resource access. In one particular implementation, the BOPS 102 server described above is configured to function as a holder for multiple 2200 users. Each user seeking to enroll with an access control platform or identity authentication system provides a variety of biographical and / or biometric data as part of the enrollment process. As such, a collection of biographical and biometric data can be considered a digital representation of the user's identity. In one implementation, this collection of biographical and biometric information is encapsulated or packaged as a portable file or data structure. In one non-limiting implementation, DID 2204 Document functions as a container or portable file for this biographical and biometric information. In one or more implementations, DID 2204 Document is a data file, container, code, or digital document that contains at least the metadata necessary to interact with a remote authentication system seeking to confirm a user's identity.In yet another example, the DID 2204 document is a single JSON object. In a further implementation, the DID 2204 document is a JSON object that conforms to the RFC 7159 specification. In one or more non-limiting implementations, a DID 2204 document described herein may include authentication and authorization information. In one particular configuration, the DID 2204 document does not contain personally identifiable information (PII). In a particular configuration of the computer systems, methods, and products described herein, a verifiable credential is stored off-chain and includes at least one or more authentication data sets or values, in addition to other personal information or credentials. In a particular configuration, the authentication data set includes a set of mechanisms that can be used to authenticate a user to an authentication system (for example, public keys, biometric templates, or even an encrypted biometric data share). Furthermore, the authentication data set included in a DID 2204 document, in a configuration, encompasses the authorization information that describes which entities can modify the DID 2204 document.For example, when a user has granted permission to a holder to alter the user's DID 2204 document, the DID 2204 document itself will include data indicating those authorized users. Furthermore, the authorization data may also include a set of service endpoints used to initiate trusted interactions with an entity, such as a service provider. As shown in Figure 22, a 2206 issuer is an entity that creates 2204 DID documents. For example, a 2206 issuer is a server or processor that is configured, through code execution, to generate a 2204 DID document in response to a 2200 user's request to enroll in an identity model. In one implementation, the 2206 issuer receives information about a potential enrollee (e.g., biographical and biometric information) and transforms that information into a 2204 DID document. However, as shown in Figure 25, the 2206 issuer itself can delegate the processor that generates the 2204 DID document to a proprietary system or server, such as a BOPS 102 server. While any entity can be a 2206 issuer, including the account holder, additional examples of 2206 issuers include corporations, governments, non-profit organizations, and / or individuals. The 2206 issuer, in one or more configurations, transmits the generated 2202 DID identifier and / or the 2204 DID document to an account holder. In one further implementation, the 2206 issuer transmits the generated 2204 DID document to a 2208 identity center. With continued reference to Figure 22, a verifiable credential has been generated and is stored in a secure location for later use. For example, the verifiable credential is stored in one or more identity hubs and repositories 2208. In this case, identity hubs and repositories 2208 are secure repositories of personal data where verifiable credentials are stored and retrieved. For example, identity hubs and repositories 2208 are one or more locally or remotely accessible data storage devices that can be accessed by user 2200, holder 102, or issuer 2206 to store, modify, or retrieve verifiable credentials. Similarly, identity hubs and repositories 2208 relay or transmit messages and data to one or more inspectors 2210.In one or more implementations, 2208 identity hubs are configured as a database or storage system, a plain file system, a relational database, or a mass storage facility accessible by a 2200 user or a 102 holder. For example, an Identity Hub may include Dropbox, Google Drive, AWS, Storj, and other similar cloud-based storage facilities. In an additional configuration, issuer 2206 (or holder 102) also generates a decentralized identifier (DID) 2202 that provides a reference to document DID 2204. In this case, the DID 2202 is a unique identifier that allows the retrieval of or access to a document DID 2204 without granting a third party direct access to the personal information referenced by the verifiable credential. In one non-limiting implementation, a DID 2202 consists of unique bits, numbers, values, strings, or sequences that are at least partially the result of the cryptographic hash function of a user's identity information contained in document DID 2204. In additional implementations, the DID 2202 is a text string, a numeric sequence, an alphanumeric or hexadecimal sequence, or any combination thereof.Furthermore, such combinations can be incorporated into one or more data files, modules, or code snippets. In yet another configuration, the identifier of DID 2202 is a URI scheme conforming to RFC 3986. For example, the identifier of DID 2202 consists of a unique string sequence followed by an optional path and / or snippet. For instance, issuer 2206 generates the identifier of DID 2202 by hashing the authentication information stored in a document DID 2202. In an alternative configuration, the identifier of DID 2202 is a unique value that corresponds to the hash value of the content of document DID 2204 and the storage location of document DID 2204. After the generation of the DID 2202 identifier, a transaction record containing the DID is added as a transaction to one or more distributed ledgers (2212). Unlike DID documents (2204), the DID 2202 identifier itself is not stored in the identity center (2208). Instead, the DID 2202 identifier is stored as a transaction in a distributed ledger or on a blockchain. Storing the DID 2202 identifier as a transaction in a distributed ledger functions as an immutable index of the DID document (2204) as well as an immutable record of the content of the DID document (2204) at the time of the DID 2202 identifier generation.Because the DID document 2204 and the DID identifier 2202 are cryptographically linked, the DID identifier 2202, when added as a transaction record in a distributed ledger 2212, provides an audit trail of the permitted exchanges between the issuer 2206, the holder or user 2200, and any third party wishing to verify the user's identity (e.g., an inspector 2210). Without being limited to any particular implementation or configuration of techniques, implementations or IVIA / a / ZUZZ / UUUOOO Distributed Ledger Specifications: The use of the term blockchain refers to one or more technologies that provide a publicly transparent and decentralized ledger that tracks and stores digital transactions in a publicly verifiable and secure configuration to prevent manipulation or revision of the underlying identity data. In one particular implementation, the blockchain or distributed ledger (2212) is a database organized as a public ledger configured to maintain a continuously growing list of data records. In this case, entries to the ledger form a blockchain by recording and linking data records using a hash function.For example, each time a new transaction is added to the blockchain (e.g., a new DID 2202 identifier), the new block includes a hash function from a previous block. In this way, each additional block creates extra security for the validity of the entire blockchain. Each block records and confirms the sequence and timing of transactions as they are created and / or recorded. Therefore, in a particular implementation, the DID 2202 identifier is stored as a transaction on the blockchain. In a particular implementation, the issuer or holder generates a DID 2202 identifier after receiving notification that a user (or holder) has provided the information to enroll on an authentication platform. When a user (2200) seeks to access protected resources, the inspector or verifier (2210) (who controls access to those protected resources) requests notifications in the form of a DID (2202) from the user or a holder representing the user in order to grant the user (2202) access to the protected resources. The inspector (2210) verifies that the credentials provided in support of a user's identity (e.g., the DID identifier (2202) and the document DID (2204) are fit for purpose and verifies the validity of the DID identifier (2202) on the blockchain (2212). By way of example, the inspector (2210) may include systems and servers maintained and provided by employers, security personnel, and websites. Turning now to Figure 23, in one or more specific implementations of the computer-implemented systems, methods, and products described herein, one or more BOPS 102 servers are configured to act as holders of the biometric shared resources (as described in the preceding paragraphs) and to enroll a user with a service provider. Referring to the flowchart in Figures 23 and 24, and the block diagram in Figure 25, a user 2202 enrolls with an issuer 2206. In this case, a user (via a browser user agent) is requested by the user device 2300, or by a software application of the same, for example, MCA, which is configured by means of one or more enrollment modules 2301, to enroll the user's biometric information with a service provider acting as the issuer 2206.In one particular implementation, the user device 2300 is configured by means of an IBV module 2303 to capture an initial biometric vector (IBV) from the user (e.g., some biometric data), as shown in step 2103. In a further implementation, the captured initial biometric vector (IBV) is encrypted across at least two shared resources while remaining local to the user's device 2300, as shown in step 2105. For example, the user's device 2300 is configured using the encryption modules 2305 to visually encrypt the IBV across two (2) or more shared resources. In this case, at least one of the encrypted IBV's shared resources is reserved on the local mobile device, as shown in step 2107. In one or more implementations, the user's device 2300 uses algorithms such as visual cryptography and Shamir secret sharing to generate a larger number of shared resources.In a non-limiting configuration, the user device 2300 is configured by means of an encrypted shared resource storage module 2307 that causes one or more of the user device 2300's local memory devices to store the encrypted shared resource for later retrieval. Continuing with Figure 23, the user device 2300 is further configured by means of a key generation module 2309 to generate a public and private key. In this case, as shown in step 2109 of Figure 24, the user device associates the public key with at least one IBV share. The public key and the encrypted share associated with the public key are transmitted from the user device 2300 to the issuing server 2600A, as shown in step 2111. While those with a basic understanding of the relevant technology will appreciate that at least one additional encrypted IBV share could be stored in an RDBMS or persistence cluster backend (e.g., Apache SOLR), the 2600A issuing server instead sends the encrypted share and public key to the BOPS 102 server along with the issuer's signature data, as in step 2013. In this case, the issuer's signature data can be any hash, code, cryptographic value, or dataset that identifies the 2600A issuing server as the source of the encrypted share and public key. For example, the issuer's signature data itself could be a public key or a public-private key pair where the issuer is the private key holder. As detailed above, the BOPS 102 server generates a DID 2204 document using both the issuer's data and the encrypted share and public enrollment encryption key. For example, the BOPS 102 server is configured using a DID 2401 generation module to generate the DID 2204 document using the issuer's signature, the public enrollment key, and / or the encrypted share, as shown in step 2115. Similarly, the DID 2401 generation module is further configured to generate the DID 2202 identifier for use with the DID 2204 document. For example, the content and location of the DID document are used to generate a unique value for the DID 2202 identifier.This value may represent a hash or something or the entire content of the DID 2204 document, as well as the particular storage location, file reference, index number, or other data that may be necessary to identify or retrieve the underlying DID 2204 document. MA / a / ¿U¿¿ / UUUUOOO As shown with respect to step 2117, the BOPS 102 server is configured by means of the DID storage module 2403 for the storage of the DID document in the identity center 2208. For example, the BOPS 102 server is configured by means of one or more APIs to access a cloud-based storage repository 2208 and for the storage of the DID document 2204 in one or more portable storage formats. Furthermore, the DID 2405 persistence module further configures the BOPS 102 server to add the generated DID 2202 identifier to a selected blockchain for persistence. This provides a blockchain-agnostic method for resolving DID 2204 documents. The DID 2405 persistence module configures the BOPS 102 server processor to generate a block of transactions for addition to an existing blockchain or distributed ledger. Alternatively, when no such ledger exists, the DID persistence module triggers the generation of a distributed ledger and adds a new transaction to it. Users with a basic understanding of the required technology will appreciate and understand the additional features, such as transaction block hashing. In one configuration, after the BOPS server 102 has registered the associated DID on a blockchain 2212, as in step 2117, the mobile device 2300 is notified of the success (or failure) of the user's enrollment. As shown in step 2119, after the user successfully enrolls with a service provider, the user will receive the DID identifier 2202 that corresponds to the user's DID document 2204. Turning to a further implementation of the user enrollment system described, Figure 25 details the data exchanges and instructions between a user 2200 and the enrollment service provider 2600. For example, a user 2200 uses a mobile application client 2300 to initiate the enrollment process. The mobile application client 2300 requests an IBV (Individual Biometric Vector) from the user 2200. The mobile application client 2300 then uses one or more imaging devices on a mobile computing platform to acquire one or more images of the enrolling user 2200 with the service provider. As further shown in Figure 25, the biometric vectors can be converted into cryptographic shares. As shown in the implementation in Figure 25, the biometric shares are converted through the use of the mobile application client 2300.Of the shared resources generated from the IBV, one is stored locally in the mobile application. Additionally, when the 2300 mobile client application provides a public and private enrollment key pair, the private key is used to encrypt the cryptographic share not stored locally in the mobile client. The encrypted share and the enrollment key pair public key are sent to Service Provider 2600 for enrollment. From that point on, as shown with respect to the implementation in Figure 25, Service Provider 2600 provides a sender signature (such as a Service Provider 2600 public key). The sender signature, enrollment public key, and encrypted share are then passed to a BOPS 102 server. 102 acts as a title for the user seeking enrollment. The BOPS 102 server generates the DID 2204 document using the issuer's signature, the encrypted share, and the public key. Once generated, the DID 2204 document serves as the basis for generating a DID 2202 identifier, which is attached to a specified and compatible blockchain 2212. After the DID 2202 identifier is generated and the corresponding DID document is stored on the blockchain, the DID 2202 identifier is returned to the mobile client application 2300 in such a way that the user retains ownership of half of the encrypted IBV share and a copy of the DID 2202 identifier. It will be appreciated that, although it is possible to store multifaceted data on the blockchain, including biometric shares, the approaches described herein do not store any personally identifiable information on the distributed ledger or blockchain 2212. The biometric shares included in DID documents 2204 are maintained off-chain through identity centers or personal storage providers 2208, and only a reference to those datasets is placed off-chain, in the form of the cryptographically aligned DID identifier 2202, within public ledger systems.As such, the encrypted biometric share generated during the enrollment process shown in Figures 24 and 25 is still encapsulated, but the reference to the encrypted share is now available via the blockchain through the associated DID 2202 identifier. Therefore, DID 2202 can be used as part of an authentication notification using either the same BOPS 102 server (as shown in Figure 23) or a different BOPS server in conjunction with a verifier. Such verification is possible because any changes to the stored DID 2204 document will become apparent when the transaction logs for DID 2202 are accessed from the 2212 blockchain. Turning to Figures 26, 27A and 27B, once a holder has associated a DID 2204 document and a DID 2202 identifier with their personal identity and has provided the user with the DID 2202 identifier, this information can be used to gain access to protected resources that are controlled by a 2600B verification server. In one particular implementation, the BOPS server 102 provides the interface between the user's data store 2208 and the verification server 2600B. However, in an additional configuration, a different BOPS server with the same or similar functionality is provided, such that the enrollment functions performed by the issuance server 2600A, as shown in Figure 23 and Figure 24, are performed by a different server than the functions performed by the verification server 2600B. In a non-limiting example shown in Figure 26, user 2200 seeks access to a resource (e.g., content or data) on a website (e.g., the service provider) through the use of a mobile client application (MCA) 2300. In this setup, user 2200 has already been configured and enrolled through the use of the BOPS-mediated enrollment platform, as provided in Figures 24 and 25. In this case, the user's particular DID identifier 2202 was created and persisted on the blockchain by the holder or issuer (as in Figures 23 to 25), and a public key created at the time of enrollment (as in step 2109) is stored in document DID 2204. As part of the user request, the user sends the service provider (verifier) ​​the DID 2202 identifier and the public key created in step 2109. In additional implementations, the user request also includes the issuer's signature. The service provider (verifier) ​​2600 passes this data to the BOPS 102 server along with a request to resolve the DID 2202 identifier over a blockchain and obtain the corresponding DID 2204 document. For example, the BOPS 102 server receives the DID 2202 identifier, and the data and public key are issued from the verification server 2600B. Just as URIs uniquely characterize web resources through URNs and URLs, the DID 2202 identifier characterizes the associated DID 2204 document through the use of one or more blockchain ecosystems. In this case, the BOPS 102 server acts as a resolver for a DID 2202 identifier, enabling the holder (BOPS 102 server) to locate the corresponding DID 2204 document. For example, the BOPS 102 server is configured using a DID 2407 resolver module to search for the received DID on one or more blockchains and use the stored transaction information to identify the relevant verifiable credential from off-chain storage, as in step 2606. As noted, in one or more configurations, the DID 2202 identifier and its corresponding DID 2204 document are cryptographically associated with each other. Therefore, any change to the DID 2204 document will cause the DID 2202 identifier to no longer be cryptographically linked to the DID 2204 document. Using this relationship, the BOPS 102 server is configured to evaluate (e.g., resolve) the DID 2204 document using the DID 2202 identifier and verify that the content of the DID 2204 document has not been modified since the DID 2202 identifier was issued, using the 2409 Claims Validation Module. For example, a new DID 2202 identifier is generated for the retrieved DID 2204 document. When the DID 2202 identifier received from the user does not match the newly generated DID identifier, the authentication process ends. Once the BOPS 102 server has accessed the DID 2204 document, the DID 2204 document itself is further evaluated to determine whether the data values ​​it contains match the notification sent by the verification server 2600B. For example, the notification validation module 2409 configures the BOPS 102 server to compare the issuer signature stored in the DID 2204 document with the issuer signature sent from the user device 2300 via the verification server 2600. In an additional configuration, the notification validation module 2409 also configures the BOPS 102 server to compare the public key contained in the DID 2204 document with the public key provided in the access request sent by the user device 2300. When the data cannot be validated against the data in the DID document, the server proceeds to the next step. 2204, then the process stops and no authorization is granted. Alternatively, when document DID 2204 is a valid notification, for example, because the identifier DID 2202 and the document DID can be cryptographically matched and the content of document DID 2204 matches the sender and encryption signatures sent by the user device 2300, the BOPS server 102 is configured by means of a verification module 2411 in order to determine whether the user can be authenticated. For example, verification module 2411 configures BOPS server 102 to request a set of biometric data from user device 2300 for comparison against the stored encrypted shared resources provided in the DID document. For example, the BOPS server sends a request to user device 2300 to request the user's candidate biometric vector (CBV), as in step 2610. In this case, the CBV is a biometric vector of the same type as the biometric identifier used to generate the IBV (as in step 2103). For example, when the IBV includes both facial recognition and speech recognition data, the CBV requested from the user will also include both facial and speech recognition data.The user device 2300, which is configured by means of a CVB request module 2704, captures the CBV of the access requesting user 2200 and transmits the CVB and the locally stored encrypted share directly to the BOPS server 102. Upon receiving the locally stored encrypted share and the user's CBV 2200, the BOPS server 102 is configured using a decryption module 2413 to decrypt the received cryptographic share and the encrypted share stored in document DID 2204, as described in step 2114. In a further implementation, the decrypted shares are combined to regenerate the original IBV. In this case, the IBV is compared to the CBV. For example, the BOPS server 102 is configured using a comparison module 2415 to compare the pixel, vector, or other data in the IBV against the same data in the CBV. As shown in step 2116, where the CBV values ​​match the IBV (or are within a predetermined IBV threshold), a match is determined and an access verification notification is sent to the verification server 2600B. Once received by the verification server 2600B, the verification server 2600B allows the user's device 2300 to access the resources provided by the service provider. After user 2200 is verified, the decrypted shared resources, IBV, CBV, and public keys are purged from the BOPS 102 server's memory. As shown in Figures 27A and 27B, a particular resource access system configuration is described. In this case, user 2200 uses MCA 2300 to access a resource (e.g., banking information, social media account, etc.) from service provider 2600. To request access, the MCA (operating on behalf of user 2200) sends the user's enrollment public key, DID identifier 2202, and issuer signature. In this case, the issuer signature is, in one implementation, a public key obtained from issuer 2600 during the enrollment process shown in Figures 24 and 25. Upon receiving these credentials from the user, the service provider establishes a session with the BOPS server 102, which acts as the account holder for user 2200. In this case, the BOPS 102 server uses the DID identifier 2202 to resolve the location of document DID 2204. In an additional implementation, the BOPS 102 server first verifies the validity of the DID identifier by evaluating the transaction record on the blockchain. As shown in Figures 27A and 27B, following the resolution of the location of document DID 2204, document DID 2204 is accessed and returned to the BOPS 102 server. Similarly, the verified credential stored in identity hub 2208 is accessed and returned to the BOPS 102 server. In one or more configurations, the verified credential is an encrypted (2 / 2) share of the user's enrollment identity. The issuer's signature stored in document DID 2204 is evaluated and verified. In addition, the public key supplied by the user is compared and verified against the public key stored in document DID 2204. Continuing with the configuration provided in Figures 27A and 27B, the BOPS 102 server sends a request to the MCA 2300 to obtain the local copy of the encrypted IBV share and a signed challenge. In this case, the signed challenge can be for a current biometric vector. For example, once the MCA 2300 receives the request from the BOPS 102 server, the MCA prompts the user to obtain a biometric identifier and encrypts the biometric identifier with the private key from the enrollment key pair. The encrypted biometric identifier, the encrypted share, and the signed challenge are then generated. As shown in more detail in Figures 27A and 27B, the signed challenge is verified by the BOPS 102 server, and the encrypted share received from the MCA is decrypted using the enrollment public key. Once decrypted, the IBV shares are combined to reform the IBV. The reformed IBV is then compared to the current biometric identifier. When there is a match, such that the current user and the enrolled user are the same, the user is granted access to the resource. Turning now to Figure 28, in one or more configurations, the user is authenticated remotely. In this case, a new service provider (for example, acting as a verifier) ​​uses one or more BOPS 102 servers configured with a remote authentication module 2417 to authenticate a user 2200, even though this user has never registered with the new service provider. In this configuration, the BOPS server acts as a holder. As shown in the workflow in Figure 28, authentication can be effectively performed using only user 2200 and the verification server 2600.This configuration contrasts with, and is an improvement over, other first-instance authentication methods, such as SAML or OAut, which rely on third-party identity providers (IdPs) to mediate identity notifications in traditional single sign-on (SSO) systems. In this case, the configuration of the provided elements allows the user to control the authentication data by using blockchain technology to secure credentials issued by one or more valid authorities (i.e., issuers) on identified blockchains, as shown in step 2910. Here, the measurable Euclidean attribute vector is stored on the respective blockchain nodes 2212 with at least the public key of the first public-private key pair. Each node in the respective distributed ledger (the blockchain) decrypts the Euclidean measurable attribute vector using the public key of the first public-private key pair and validates the Euclidean measurable attribute vector. Furthermore, each node is configured to append the Euclidean measurable attribute vector to the respective ledger of the 2212 nodes. The described method further includes the reception, from a 2300 mobile computing device via a data communication network, of a current biometric vector representing the encrypted biometric entry record, as shown in step 2912. The received current biometric vector is provided, as shown in step 2914, to the neural network, where the neural network translates the current biometric vector to a current Euclidean measurable attribute vector. In one configuration, the current Euclidean measurable attribute vector is signed, as in step 2916, and encrypted as in step 2918 through the use of a private key from a second public-private key pair. The signed and encrypted current Euclidean measurable attribute vector is distributed among the plurality of ledgers 2212 stored on the respective nodes along with the public key from the second public-private key pair, as in step 2920. As detailed more fully, each of the respective nodes of the plurality of distributed ledgers is configured in such a way as to decrypt the current Euclidean measurable attribute vector through the use of the public key of the second public-private key pair, and to validate the current Euclidean measurable attribute vector as in step 2922. In addition, each respective node is configured in such a way as to perform a search of at least some of the Euclidean measurable attribute vectors stored in the ledger through the use of the current Euclidean measurable attribute vector.For example, as shown in step 2924, the biometric entry record is matched with at least one biometric record as a function of an absolute distance calculated between the current Euclidean measurable attribute vector and a calculation of each of the respective Euclidean measurable attribute vectors in the ledger portion. As used herein, "processor" or "computer" refers to one or more electronic devices (for example, semiconductor-based microcontrollers) configured with code in the form of software to execute a specific set of instructions. For example, the evaluation server 102, databases 108, and remote access devices 104 each include one or more processing or computing elements that run commercially available or custom operating system implementations, such as Microsoft Windows, Apple macOS, UNIX, or Linux-based operating systems. In other implementations, the evaluation server 102, databases 108, and remote access devices 104 each include custom or non-standard hardware, firmware, or software configurations.For example, a processor or computer may include one or more components from a collection of microcomputing elements, such as a computer-on-a-chip, field-programmable gate arrays, graphics processing units, home entertainment consoles, media players, set-top boxes, prototyping devices, or hobby computing elements. These computing elements are connected, directly or indirectly, to one or more memory storage devices (memories) to form a microcontroller architecture. Memory is a persistent or non-persistent storage device used to store the processor's operating system and one or more software modules.According to one or more modalities, memory comprises one or more volatile and non-volatile memories, such as read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), single-in-line memory (SIMM), dual-in-line memory (DIMM), or other types of memory.Such memories may be fixed or removable, as is known to those with ordinary experience in the subject, such as through the use of removable media cards or modules, an object-oriented database, a hybrid relational-object database, a key-value data store such as Hadoop or MongoDB, and other systems for data structuring and retrieval that are well known to those skilled in the art. Database 108 includes the hardware and software necessary to enable a local processor of the content evaluation server 102 to retrieve and store the data within Database 108. Computer memory can also include secondary storage, such as magnetic or optical disk drives or flash memory, which provide long-term data storage similar to persistent memory devices. In one or more forms, processor memory provides storage for application programs and data files as needed. The processors or computers described are configured in such a way as to execute code written in a standard, custom, proprietary, or modified programming language, such as a standard set, subset, superset, or extended set of JavaScript, PHP, Ruby, Scala, Erlang, C, C++, Objective-C, Swift, C#, Java, Assembly, Go, Python, Perl, R, Visual Basic, Lisp, TensorFlow for ML, mClust, or Julia, or any other object-oriented, functional, or other paradigm-based programming language. In a particular implementation, the processing computers are deployed as one or more of a server, computing cluster, cloud platform, or computing array, which are configured in such a way as to communicate and exchange data directly or through a communication link with one or more remote access devices, such as mobile phones, tablets, workstations, desktop computers, or other computing elements. As provided in the illustrated implementations, computers and processors are configured by the code running on them to accept electronic data queried from one or more remote data storage locations (e.g., databases) and to evaluate the queried or accessed data according to predetermined or dynamic rules, logic, instructions, or algorithms. The physical structure of the databases may be incorporated as solid-state memory (e.g., ROM), hard disk drive systems, RAID, disk arrays, storage area networks (SANs), network-attached storage (NAS), and / or any other system suitable for storing computer data. In addition, the database may comprise caches, including database caches and / or web caches.Programmatically, a database can comprise a plain file data store, a relational database, an object-oriented database, a hybrid relational / object database, a key-value store such as Hadoop or MongoDB, and other data structuring and retrieval systems well-known to those with technical expertise. The database includes the hardware and software necessary to enable a local processor on such servers to retrieve and store data within the database. As used herein, remote access devices are used to exchange data, such as emails, data packets, streams, or files, across a network with one or more local or remote computers or processors (e.g., a server). In one implementation, remote access devices connect directly to servers, for example, via an internal local area network. Alternatively, remote access devices are configured with the appropriate software and hardware to connect to servers by first establishing an internet connection. As used herein, a remote access device is a general-purpose or single-purpose computing device that is configured through hardware or software modules to connect to a network and receive data.For example, a remote access device can be a personal communication device (smartphone, tablet computer, etc.) configured using one or more code modules to exchange data with the contents of one or more computers or processors. Remote access devices are configured using wired or wireless communication media, such as, but not limited to, CDMA, GSM, Ethernet, Wi-Fi, Bluetooth, USB, serial communication protocols, and hardware to connect to one or more access points, exchanges, network nodes, or network routers.In a particular configuration, remote access devices are also configured, through hardware and software modules, in such a way as to connect to more remote servers, computers, peripherals, or other hardware through the use of standard or custom communication protocols and configurations (e.g., TCP / IP, etc.) either through a local or remote network or through the Internet. In one implementation, the remote access devices, processors, and computers run custom or commercially available operating system implementations, such as Microsoft Windows, Apple macOS, UNIX, or Linux-based operating systems. In other implementations, the remote access devices, processors, and computers are custom or non-standard hardware, firmware, or software configurations. These devices, processors, and computers can communicate with one or more remote networks using USB, digital input / output pins, eSATA, parallel ports, serial ports, FireWire, Wi-Fi, Bluetooth, or other communication interfaces. While this specification contains many implementations and specific details, these should not be interpreted as limitations on the scope of any configuration, arrangement, implementation, or modality, or on what may be claimed, but rather as descriptions of features that may be specific to particular implementations or to one or more particular modalities. Certain features described in this specification in the context of separate implementations may also be implemented in combination in a single configuration or arrangement. Conversely, several features described in the context of a single implementation may also be implemented in multiple separate configurations or arrangements or in any suitable subcombination.Furthermore, although the features may be described above as acting in certain combinations and even initially claimed as such, one or more features of a claimed combination may in some cases be removed from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. Similarly, while the operations are illustrated in the diagrams in a particular order, this should not be understood to mean that these operations must be performed in the specific order shown or sequentially, or that all the illustrated operations must be performed, to achieve the desired results. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the ways described in the preceding paragraphs should not be understood as requiring such separation in all cases. It should be understood that the program components and systems described can generally be integrated into a single software product or packaged into multiple software products. The terminology used herein is intended to describe only the particular embodiments and is not intended to limit the invention. As used herein, the singular forms a, an, and the are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is further understood that the terms comprise and / or comprising, when used herein, specify the presence of the features, whole numbers, steps, operations, elements, and / or components mentioned, but do not exclude the presence or addition of one or more different features, whole numbers, steps, operations, elements, components, and / or groups thereof. It should be noted that the use of ordinal terms such as first, second, third, etc., in claims to modify an element of the claim does not in itself imply any priority, precedence, or order of one element of the claim over another, or the temporal order in which the acts of a method are performed. Rather, they are used simply as labels to distinguish one element of the claim with a particular name from another element with the same name (except for the use of the ordinal term). Furthermore, the phraseology and terminology used herein are for descriptive purposes and should not be considered limiting.The use of terms including, comprising, having, containing, involving, and variations thereof in this document is intended to encompass the items listed below and their equivalents, as well as additional items. The specific embodiments of the subject matter have been described in this specification. Other embodiments are within the scope of the following claims. For example, the actions mentioned in the claims can be carried out in a different order and still achieve the desired results. As an example, the processes illustrated in the accompanying figures do not necessarily require the specific order shown, or the sequential order, to achieve the desired results. In certain embodiments, multitasking and parallel processing may be advantageous. Throughout this application, publications and references to well-known trademarks representing various systems are cited, and disclosures of these are incorporated herein by reference. The citation of any prior publication or document is not intended as an admission that any of the foregoing constitutes the relevant prior art, nor does it constitute any admission as to the content or date of these publications or documents. All references cited herein, including issued and pending patents and patent applications, are incorporated by reference to the same extent as if each individual publication and reference were specifically and individually indicated as incorporated by reference. Although the invention has been shown and described in a particular manner with reference to a preferred embodiment thereof, persons skilled in the art will understand that various changes may be made to its form and details without departing from the spirit and scope of the invention. As such, the invention is not defined by the discussion in the preceding paragraphs, but rather by the points that follow, by the respective features mentioned in those points, and by equivalents of those features.

Claims

1. A computer-implemented method for registering an identity with an authentication system, wherein the method comprises: receiving, from a mobile computing device via a data communication network, at least one encrypted cryptographic share of an initial biometric vector (IBV) and a public key from a first public-private key pair that is mathematically generated through the use of a seed, wherein the at least one encrypted cryptographic share has been encrypted through the use of a private key from the first public-private key pair; generating a first identity data set that includes at least one authorization system signature, the public key from the first public-private key pair, and the at least one encrypted cryptographic share;the storage of the first set of identity data in at least one remote storage location; the generation of an identity reference value that is associated with the first set of identity data, wherein the identity reference value resolves the storage location of the first set of identity data and is cryptographically associated with the first generated set of identity data; the distribution, among each of a plurality of ledgers stored on the respective nodes, of a transaction record that includes at least the identity reference value; the provision, to the mobile computing device, of at least the identity reference value.

2. The method according to claim 1, wherein the encrypted shared resource received from the IBV is generated by providing the initial biometric vector to a neural network, wherein the neural network translates the initial biometric vector to a measurable Euclidean attribute vector and encrypts the measurable Euclidean attribute vector through the use of the private key of the first public-private key pair.

3. The method according to what is claimed in claim 1, wherein the IBV is visually encrypted through the use of the Shamir Secret Sharing Schema algorithm.

4. A system for providing a user with access to a resource provider, wherein the system comprises: a processor having memory and configured by means of one or more modules to: receive, from a mobile computing device via a data communication network, at least: an identity reference value associated with a first identity data set, wherein the identity reference value resolves the storage location of the first identity data set and is cryptographically associated with the first identity data set, wherein the first identity data set includes at least one authorization system-specific data value, a public key from a public-private-key enrollment pair that is mathematically generated through the use of a seed,and at least one remote encrypted cryptographic share of an initial biometric vector of a user requesting access; an authorization system signature value; the public key of the enrollment public-private key pair; locate, among a plurality of ledgers stored on the respective nodes, a transaction record that includes at least the identity reference value; determine, from the located transaction record, a storage location of a corresponding first set of identity data; access the cryptographically associated first set of identity data; verify the authorization system signature value and the enrollment public key of the first set of identity data; receive, from the mobile computing device,a current biometric vector and a locally encrypted biometric cryptographic share; decrypt the received locally encrypted cryptographic share and the remotely encrypted cryptographic share through the use of the public key of the enrollment public-private key pair; combine the decrypted local cryptographic share and the decrypted stored cryptographic share to form a combined cryptographic vector; compare the combined cryptographic vector with the current biometric vector; and where the combined cryptographic vector matches the current biometric vector, causing the resource provider to grant the user access to the resource.

5. The system according to what is claimed in claim 4, wherein the comparison of the combined cryptographic vector with the actual biometric vector includes: providing a combined cryptographic vector and the actual biometric vector to a neural network, wherein the neural network translates the combined cryptographic vector and the actual biometric vector to the respective measurable Euclidean attribute vectors.

6. The system according to what is claimed in claim 5, wherein the combined cryptographic vector is compared to the actual biometric vector as a function of an absolute distance that is calculated between the respective Euclidean measurable attribute vectors of the combined cryptographic vector and a calculation of each of the respective Euclidean measurable attribute vectors of the actual biometric vector.

7. The system according to what is claimed in claim 5, wherein the processor is further configured to: classify the Euclidean measurable attribute vector; and / or classify the actual Euclidean measurable attribute vector, wherein the classification is carried out at least in part through the use of one or more distance functions.

8. The system according to what is claimed in claim 7, wherein the classification of the Euclidean measurable attribute and / or the actual Euclidean measurable attribute vector returns floating-point values, and a Frobenius algorithm is used to calculate an absolute distance between each floating-point and its average.

9. The system in accordance with what is claimed in claim 7, wherein the search is carried out at the time of registration of the Order.

10. The system according to what is claimed in claim 7, wherein the processor is further configured to: through the use of a Frobenius algorithm, classify the measurable Euclidean biometric vectors; traverse a hierarchy of the measurable Euclidean biometric vectors classified at the time of registration of the Order; and identify that a respective measurable Euclidean biometric vector is the current measurable Euclidean attribute vector.

11. The system according to what is claimed in claim 5, wherein the processor is further configured to: identify, for each respective measurable Euclidean biometric vector, a plurality of floating-point values; and use a bitmap to remove from any absolute distance calculation from the plurality of values ​​that are not present in each vector.

12. The system according to what is claimed in claim 5, wherein the processor is further configured to: identify, for each respective measurable Euclidean biometric vector, a plurality of floating-point values; and define a sliding scale of importance based on the number of vectors in which a respective floating-point value appears.

13. The system according to what is claimed in claim 5, wherein the neural network is configured with a variety of convolutional layers, together with a rectifier (ReLU) and clustering nodes.

14. The system according to what is claimed in claim 5, wherein the neural network is configured to use clustering as a form of nonlinear top-down sampling, and further wherein one or more clustering nodes progressively reduce the spatial size of a represented Euclidean measurable attribute vector to reduce the number of parameters and computations in the neural network.

15. The method according to what is claimed in claim 14, wherein the processor is further configured to: calculate, for each of a plurality of stored Euclidean measurable attribute vectors, a relative position difference between an average face vector and the respective Euclidean measurable attribute vector; square the relative position difference; sum the values; and calculate the square root.

16. The system according to what is claimed in claim 5, wherein the performance of the neural network is determined as a function of a cost function, wherein a number of layers is calculated as a given spatial size of an output volume as a function of an input volume size W, a kernel field size of layer neurons K, a rate at which the layers are applied S, and an amount of zero padding P used on an edge.

17. The system according to what is claimed in claim 5, wherein the neural network translates the initial biometric vector to the current biometric vector as a function of matrix multiplications for each respective layer and uses a Euclidean distance algorithm based on a Euclidean cost function.

18. A computer-implemented method for matching a biometric entry record with a biometric record stored in a plurality of distributed ledgers, wherein the method comprises: providing an initial biometric vector to a neural network, wherein the neural network translates the initial biometric vector into a Euclidean measurable attribute vector; digitally signing the Euclidean measurable attribute vector through the use of a private key from a first public-private key pair; encrypting the Euclidean measurable attribute vector through the use of a public key from a first public-private key pair;distribute, among the plurality of ledgers stored in the respective nodes, at least the encrypted Euclidean measurable attribute vector and the public key of the first public-private key pair, wherein each respective node: decrypts the Euclidean measurable attribute vector through the use of the public key of the first public-private key pair; validates the Euclidean measurable attribute vector; and attaches the Euclidean measurable attribute vector to the respective ledger of the nodes; receive, from a mobile computing device via a data communication network, a current biometric vector representing the encrypted biometric entry record; provide the current biometric vector to the neural network, wherein the neural network translates the current biometric vector to a current Euclidean measurable attribute vector;digitally sign the current Euclidean measurable attribute vector through the use of a private key from a second public-private key pair; encrypt the current Euclidean measurable attribute vector through the use of a public key from the second public-private key pair; distribute, among the plurality of ledgers stored in the respective nodes, at least the current Euclidean measurable attribute vector and the public key from the second public-private key pair, wherein each respective node: decrypts the current Euclidean measurable attribute vector through the use of the public key from the second public-private key pair; validates the current Euclidean measurable attribute vector;and performs a search of at least some of the Euclidean measurable attribute vectors stored in the ledger through the use of the current Euclidean measurable attribute vector, wherein the biometric entry record is matched with at least one biometric record as a function of an absolute distance calculated between the current Euclidean measurable attribute vector and a calculation of each of the respective Euclidean measurable attribute vectors in the portion of the ledger.; 19. The method according to what is claimed in claim 18, wherein the Euclidean measurable attribute vector is validated as a function of the decryption of the Euclidean measurable attribute vector through the use of the private key of the first public-private key pair, and it is verified that no alteration of the Euclidean measurable attribute vector occurred by comparing the Euclidean measurable attribute vector of each node with the decrypted Euclidean measurable attribute vector.

20. The method according to what is claimed in claim 18, wherein the signature of the Euclidean measurable attribute vector comprises: generating a hash value associated with the Euclidean measurable attribute vector; and encrypting the hash value through the use of the private key of the first public-private key pair, wherein the hash value is decrypted by each respective node through the use of the public key of the first public-private key pair and compared to the hash value that is decrypted through the use of the private key of the first public-private key pair.

Images