• Latch Backend: Es el servidor de Latch. Este servidor gestiona los Latches para las apps del mundo Web2, y va a manejar el Latch SmartContract para mantener los "Latches Web3" de las aplicaciones Web3. Es un servicio web al que los desarrolladores Web2 llaman para las opciones de Pareado, Despareado y Consulta del Latch, y los desarrolladores Web3 tendrán que llamar para las opciones de Pareado y Despareado, ya que la opción de consultar un Latch Web3 se hará con una llamada del SmartContrat.

• Latch Developer: Es una cuenta Web2 que un desarrollador tendrá que sacarse en el Latch Backend para poder crear las aplicaciones Web2 y Web3 para las que se van a crear Latches o Latches Web3 que protegerán partes de las aplicaciones Web2 y/o Web3.

• Latch ApplicationID: Cuando un desarrollador quiere proteger una aplicación Web2 o Web3, se generar una identidad para esa aplicación en el mundo Latch, que se llama ApplicationID. Se utilizará para el proceso de pareado y despareado de usuarios a aplicaciones.

• Latch UserID: Cada usuario que quiere poner un 2FA en sus aplicaciones, tanto Web2 como Web3, primero tiene que tener una cuenta en el servidor de Latch. Esta es cuenta con la que gestionará el pareado, la apertura y el cierre de latches, y con la que un usuario iniciará sesión en la app de Latch en el terminal móvil. Aunque se proteja un SmartContract del mundo Web3, Latch sigue siendo una aplicación del mundo Web2.

• Latch App: Es la aplicación móvil que maneja el usuario para realizar el pareado y despareado de Latches, para cambiar el estado. Se autentica siempre contra el Latch Backend. Es una arquitectura Web2 clásica.

Figura 26: Latch App con el nuevo diseño

• Latch Pairing Token: El Token de pareado es un TOTP que se genera el Latch USERID en la app móvil de Latch para generar un Latch en una Latch Application. Es decir, el usuario pide un Token de pareado en la app de Latch, se lo entrega a la aplicación en la que quiere crear el Latch, y la aplicación hablará con el Latch Backend para crear el Latch. El Latch concreto será lo que llamamos AccountID que explico aquí.

• Latch AccountID: Este es el Latch. Cuando se hace un proceso de Pareado, lo que se crea en la base de datos de Latch Backend es un AccountID, cuando se desparea un usuario de un ApplicationID se elimina este AccountID, cuando se cambia el estado del Latch se cambia el valor de este AccountID y cuando se consulta el estado de un Latch, se consulta el estado del AccountID. En el mundo Web2, este AccountID es necesario controlarlo en las aplicaciones protegidas por Latch. En el mundo Web3, vamos a ver que este AccountID no lo utilizamos para consultar el estado desde los SmartContract de la DApp que se protege, ya que utilizaremos la dirección pública de la Wallet del usuario. No obstante, en el mundo Web3 este AccountID sigue existiendo en el Backend de Latch y es lo que cambia el usuario de Web3 desde su app de Latch en el terminal móvil.

• Latch SmartContract: Nuestro Latch BackEnd se ha extendido y tiene una pieza nueva en forma de SmartContract que gestiona nuestra DApp. Es decir, el Latch SmartContract es una extensión de Latch Backend en una cadena de bloques. De momento, está desplegado solo en Polygon, porque aún estamos en fase alfa de este servicio. Es el que va a permitir a cualquier SmartContract de la red Polygon consultar el estado de los Latches. Además, cuando un usuario de Latch cree o cambie el estado de un AccountID en su aplicación móvil de Latch, el Latch BackEnd utilizará este SmartContract para anclar el estado de ese Latch Web3 de ese usuario en la BlockChain de Polygon.

Figura 28: Diagrama de arquitectura Latch Web3.

• Latch Web3 Developer Wallet: Un desarrollador que quiera usar Latch para proteger el SmartContract de una Dapp, deberá tener una Wallet. Esta la va a necesitar para firmar la creación de la Latch Web3 Application.

• Latch Web3 User Wallet: Si el usuario quiere firmar un transacción en el SmartContract de una DApp, tendrá obligatoriamente que tener una Wallet. Si quiere tener un Latch Web3 para proteger su cuenta en ese SmartContract de la Dapp, deberá tener un usuario de Latch también. Es decir, esta wallet es la identidad Web3 del usuario en la Dapp con la que se parea un Latch UserID.

• Latch Web3 Account Status: Este es el equivalente al Latch AccountID de Web3 en la Web3. En este caso, el Latch Web3 Account Status es un valor que se almacena en un bloque de la BlockChain de Polygon. Este valor lo escribe y lo actualiza el Latch SmartContract manejado por el BackEnd de Latch, y lo consulta el SmartContract de la DApp protegida por Latch mediante llamadas al Latch SmartContract.

• Latch Web3 Application (APP_ID): Para que se puedan parear usuarios de Latch con el SmartContract de la Dapp, es necesario que el Latch Developer creer una Latch Web3 Application. Para ello, deberá firmar la creación de esta aplicación con su Latch Web3 Developer Walled. Y se creará un ApplicationID que se utilizará para el pareado y despareado de Latches, así como para el cambio de estado de estos en el BackEnd de Latch.

• Latch Web3 Application Secret Key: Para poder llamar a la función de parear o desparear, el desarrollador deberá utilizar una contraseña, en forma de SECRET_KEY que recibirá cuando se cree la Latch Web3 Application en la herramienta de administración de Latch.

• DApp SmartContract: Es el encargado de la lógica Web3 que hay detrás de una DApp. Deberá integrar las capacidades de Latch, y luego en cada llamada de ejecución que reciba desde una dirección pública de la wallet de un usuario, podrá consultar el estado del Latch Web3 de ese usuario mediante una llamada la Latch SmartContract usando la función getStatus() del SmartContract de Latch, que devolverá el estado del Latch para cada usuario.

Es importante notar que, con esta arquitecta, actualmente el pestillo de Latch será único para todos los métodos protegidos. Es decir, un usuario podrá tener un Latch por SmartContract a proteger. El soporte a operaciones, que permite que un usuario maneje ene latches en una aplicación estará disponible en versiones posteriores. 

• DApp SmartContract: Este será el encargado del proceso de pareado y despareado de los Latches. Para ello, deberá llamar a las funciones de pareo y de despareo en formato Web3 y haciendo uso de ApplicationID, el Token de Pareado, el Secret Key para garantizar que es el dueño de la Latch Web3 Application, y la dirección pública del Wallet del usuario que está creando el Latch, que lamamos WEB3WALLET, y que es una dirección Ethereum pública del usuario que desea parear el servicio, y por último, para que no pueda crear un Latch Web3 cualquiera, el valor WEB3SIGNATURE, que es una firma de la cadena “Latch-Web3” por parte del usuario con su clave privada, y que es es una forma de certificar que el usuario dispone de dicha clave privada.

Figura 32: Ejemplo de pareado para generar un Latch Web3