- ¿Qué es un Auth DID?
- ¿Qué es un DKMS?
- El flujo de trabajo para la verificación de la identidad en SSI
- ¿Por qué son esenciales para la SSI?
Volvemos con nuestra quinta guía sobre la Identidad Autosoberana en la que explicaremos cómo funcionan el DID Auth y el Decentralized Key Management System? (DKMS), los dos pilares tecnológicos adicionales que, junto con los Decentralized Identifiers y las Verifiable Credentials, son fundamentales para la implementación de este nuevo estándar de identidad digital.
¿Qué es un DID Auth?
En el mundo de la Identidad Auto Soberana, una de las primeras preguntas que deben hacerse los usuarios es: pero si no hay nadie que me proporcione mi identidad, ¿cómo demuestro a terceros que existo?
Hemos explicado en guías anteriores que mi identidad digital viene dada por lo que otros usuarios dicen de mí dentro de un mundo virtual, donde la identidad personal se caracteriza por los Decentralized Identifiers(DID). Un mundo de DIDs que se conectan entre sí. Más técnicamente, podemos imaginar nuestra identidad como una identidad funcional que viene determinada por las credenciales verificables que nos proporcionan terceros y las conexiones que nuestro DID ha creado con otros compañeros. Sin embargo, el problema se desplaza. Si yo mismo controlo y genero mi propio DID, ¿cómo puedo demostrar que este DID está controlado por mí y me representa?
Aquí es donde entra en juego el papel de los DID Auth.
El término DID Auth se ha utilizado de diferentes maneras y actualmente no tiene una definición específica. Sin embargo, podemos definir el DID Auth como una ceremonia virtual en la que un propietario de una identidad digital, con la ayuda de varios componentes como los navegadores web y los dispositivos móviles, demuestra a una contraparte que tiene el control total de un DID específico en ese preciso momento. Evidentemente, cuando se habla de Auth DID, se incluye la capacidad de establecer canales de comunicación mutuamente autentificados y/o la capacidad de autentificarse a través del propio DID mediante sitios web y/o aplicaciones digitales.
Más técnicamente, para demostrar el control de un DID hacia una contraparte, se utiliza un mecanismo que se describe y especifica dentro de lo que definimos en la última guía como documentos DID.
Los documentos DID pueden considerarse como folletos de instrucciones que acompañan a los DID, dentro de los cuales hay diversos metadatos que ayudan a las contrapartes a identificar a la contraparte durante una conexión. Sin embargo, parte de la información relativa a los métodos de identificación implica a los sistemas de gestión de claves descentralizadas (DKMS), así que vayamos por orden.
¿Qué es un DKMS?
En el mundo offline, gestionamos nuestras credenciales en el interior de una cartera física: esto es así porque nos ayuda a no perderlas, las protege manteniéndolas cerca de nuestro cuerpo y las hace fáciles de llevar y accesibles cuando las necesitamos. El trabajo de un monedero digital no debería ser diferente: debería almacenar tus credenciales, mantenerlas a salvo de posibles hackers o ciberataques y, por último, deberían ser cómodas de mostrar en todos los dispositivos de uno, pero al mismo tiempo, fáciles de ocultar de miradas indiscretas.
Por desgracia, a lo largo de los años 90 y 00 hubo tantos intentos equivocados de carteras digitales que muchos desarrolladores dejaron de utilizar el término. Sin embargo, con la aparición de las criptomonedas, la investigación y el desarrollo de las famosas criptocarteras (crypto wallet) han dado por fin un nuevo impulso a estas aplicaciones digitales.
Estos tipos de wallet se basan en una rama de las matemáticas, más concretamente en la criptografía, denominada criptografía de clave pública o criptografía asimétrica. La idea es la siguiente: un usuario tiene una clave privada, que debe mantenerse a salvo y no debe mostrarse a nadie, y tiene una clave pública que puede mostrarse y que permite al usuario identificarse ante sus homólogos. De la clave pública no se obtiene más información que la clave privada, sin embargo, esta última se genera únicamente a partir de la clave privada.
Mediante el uso de la clave privada, el usuario puede operar y “desbloquear” operaciones y la clave pública se utilizará para demostrar a terceros que esas operaciones han sido realizadas por él. Por ejemplo, en el caso de Bitcoin, la clave privada permite al usuario gastar bitcoins, mientras que la clave pública (más exactamente una representación reducida de la misma, definida como la dirección pública) se muestra para recibir otros bitcoins de terceros.
Pero, ¿Cuáles son las relaciones entre estas claves y los elementos de la Self-Sovereign Identity? Simple, cada DID es imaginable como una dirección pública generada por una clave pública que a su vez ha sido generada por una clave privada. Te recuerdo, además, que el sentido de las generaciones es unidireccional, es decir, desde el DID nunca puedo volver a la clave privada, sino que por el contrario desde la clave privada puedo volver a mi DID. Por lo tanto, un monedero para SSI tendrá que ser un contenedor de estos 3 elementos fundamentales y es la herramienta propietaria que permite al usuario realizar operaciones y conexiones con otros usuarios.
Además, a diferencia de un monedero de criptomonedas tradicional (para aquellos que ya tienen algo de experiencia con Bitcoin, etc.) un DKMS también tendrá que tener estas funciones:
- Tendrá que cumplir con las normas abiertas de la Self-Sovereign Identity;
- Debe permitir que las conexiones realicen un intercambio verificable de credenciales (VC) entre los agentes durante las identificaciones;
- Debe poder conectarse fácilmente a otros sistemas a través de API u otros protocolos de comunicación informática;
- Debe aceptar y resolver cualquier tipo de credencial verificable (VC) basada en su extensión;
- Deberá poder instalarse en cualquier dispositivo;
- Tendrá que ser capaz de realizar fácilmente copias de seguridad y trasladar las claves y credenciales de un monedero a otro;
Por cierto, si lo piensas bien, todas estas características están diseñadas para crear una copia digital, o como solemos usar un “gemelo digital” de nuestra vieja cartera de cuero que usamos a diario: fácil de usar, llevar, llenar y vaciar.
El workflow para la verificación de la identidad en el SSI
Ahora vamos a tratar de entender cómo funciona la relación entre DID Auth y DKMS con respecto a la verificación de una identidad en SSI.
Hemos dicho que DID Auth es un mecanismo que permite a un usuario demostrar a un tercero que tiene un identificador descentralizado (DID). Mientras que los DKMS son contenedores dentro de los cuales hay DIDs y claves criptográficas. Además, ya hemos mencionado que los documentos DID se utilizan para ayudar al usuario a demostrar que es propietario de un DID concreto. Pero, en realidad, ¿Qué significa eso?
Dentro del Documento DID genérico es posible encontrar varios campos, entre ellos nos interesa el definido como “autenticación”. La autenticación se refiere al uso de las propias claves criptográficas, es decir, la clave pública y la clave privada, asociadas al DID.
Gracias a la clave privada, el usuario puede resolver un reto creado por el DID Auth y gracias a su clave pública puede demostrar que ha resuelto dicho reto. Esta resolución se denomina prueba criptográfica.
La prueba criptográfica es un valor alfanumérico que se comunica dentro del documento DID, de manera que sea público para todas las partes que intervienen en el proceso de verificación.
Este mecanismo de prueba lo realizará el usuario a través de su DKMS, que se comunicará con el DID Auth de la otra parte, imaginable como un botón “Sign in with DID Auth” dentro de una web o aplicación. A través de esta modalidad, el usuario podrá identificarse ante terceros y demostrar que posee ese DID.
¿Por qué son fundamentales para la ISS?
Hay varias razones: la primera, sin embargo, es una de las más importantes.
Una de las grandes ventajas de la Self-Sovereign Identity es la posibilidad de poder crear cientos y cientos de identidades propias en función de las relaciones y conexiones que el usuario quiera crear. Más técnicamente significa que un usuario podría crear un nuevo DID para cada nueva relación que esté creando. Sin embargo, esto supondría almacenar cientos y cientos de códigos alfanuméricos, algo que reto a cualquiera a ser capaz de hacer sin volverse loco. En realidad, los DKMS consisten en disponer de contenedores fáciles de usar, dentro de los cuales un usuario general puede encontrar y manejar fácilmente todas sus identidades.
En segundo lugar, gracias al DID Auth, la identidad autosuficiente podrá competir con otros modos de reconocimiento digital de forma similar al “Login With Facebook”, etc. Siempre recordamos que la user experience y la facilidad de uso son los principales escollos a la hora de la adopción.
En tercer lugar, el desafío Auth DID podemos considerarlo como una credencial verificable “especial”. Especial porque sólo después de la resolución del desafío de DID Auth, las otras credenciales verificables pueden ser intercambiadas (durante cualquier otra verificación), y entonces la prueba de DID Auth es una parte integral de la verificación de identidad.
Con esta guía hemos comprendido mejor cuáles son todos los elementos fundamentales para la puesta en marcha de la Self-Sovereign Identity. Además, en la próxima guía veremos por fin el uso real de blockchain dentro de este nuevo mecanismo de gestión de identidades.