 ¿Puedo usar la pantalla o necesitas alguna...? No, no, no, no, no. Es ok. Ok, David, perdón pero voy a hablar en español. No, no, no, por favor, por favor, por favor, por favor, y tú también estás vivo en Youtube. Yo también. Es muy difícil en español. Si. Eh... bueno. Ok. ¿Están listos entonces? Buenas. Hola, ¿qué tal? Bienvenidos a HyperLayer Madrid, una vez más. Muchísimas gracias por vuestro tiempo y por asistir. Hoy tenemos a Dani Suárez, que nos va a contar sobre HyperLayer Indie y sobre cómo emprender con CELSOBRAIN Identity. Dani es un ingeniero de software y emprendedor latinoamericano, apasionado por las criptomonedas del blockchain, que ha participado en programas de emprendimiento de talla mundial como Startup Chile para el 18 en Puerto Rico y la participación en la primera incubadora de Digital CELSOBRAIN Identity en San Francisco, California. Bueno, es miembro fundador de tres startups, así que, bueno, nos va a contar muchísimos experiencias hoy aquí. Y nada, a comentaros, sí, la presentación se va a quedar en YouTube, estamos transmitiendo en YouTube en streaming, de hecho, por si os queréis cambiar allí, pues, por si lo queréis poner en la Smart TV o lo que sea. Y nada, como siempre, la charla se queda subida a YouTube en el canal de HyperLayer, por si queréis volver a repetirla o verla, pues, en otro momento o lo que fuera. Y nada, y comentaros que para el mes que viene, tenemos un Meetup o otro Meetup que se está organizando, que todavía no he podido publicarlo, porque todavía no tengo cerrada la fecha, pero será la última semana de mayo, que consistirá sobre HyperLayer Aries. La única cosa es que nos ha costado muchísimo encontrar speakers que hablen castellano o español. Entonces, bueno, en este caso, la charla será en inglés. También, de todas maneras, hago un llamamiento a speakers. Si alguien quiere, en algún momento, compartir, pues, siempre en torno al tema de HyperLayer, de cualquier proyecto, su experiencia, que nos cuente en profundidad el proyecto, etcétera. Bueno, pues, la charla es más que bienvenida. Y, bueno, si en concreto habéis trabajado con indies, también compartir la experiencia, pues, bueno, estamos siempre buscando speakers que hablen en nuestro idioma, pues, por contribuir a la comunidad en nuestro idioma y que tengamos también material y contenidos en castellano. Así que, nada, Dani, te cedo la palabra. Muchísimas gracias por estar aquí por tu tiempo. Y nada, espero que os resulte muy interesante. Dani, ¿te hemos perdido? Te hace un mute. Vale, ya. Gracias. Listo. Bueno, pues, un gusto saludarlos a todos. Muchas gracias por participar en esta charla el día de hoy. El nombre de esta charla es, emprendiendo con CELV Sovereign Identity, una tecnología que tiene un gran potencial para nuestra actual generación y las futuras generaciones. Y, aún, digamos, que no se termina de ver el verdadero potencial debido muchas veces a que el blockchain solamente lo ven como criptomonedas y, realmente, el blockchain es mucho más que eso, sí. Mi nombre es Dani Suárez. Yo soy el consumidor de tres startups, una startup que se llama OIGAME, que tiene que ver con fines sociales. Es una startup de recolección y análisis de denuncias ciudadanas. Otra startup se llama HONDOS, que es una fintech en el sector de la construcción. Y la startup por la que estoy hoy aquí es Certify, que tiene como fin a ayudar al intercambio de información segura entre personas e instituciones alrededor del mundo. Y para dicho intercambio, nosotros empleamos la tecnología blockchain, lo que brinda transparencia y confiabilidad a la hora de intercambiar información. Los temas que vamos a tratar hoy es, primero, poner un contexto del mundo centralizado en el que en ese momento vivimos. Segundo, darles una breve introducción del concepto de zero knowledge proof. Después, hablar un poco de self-sovereign identity y verifiable credentials en qué consisten estos conceptos. Cuarto, hablar un poco, un scope, un overview de Hyperledger y sus librerías para self-sovereign identity. Quinto, mostrarle un poco acerca de algunos. Dani, te hemos perdido. Perdón, perdón. Quinto, hablarles un poco acerca de las soluciones actuales de algunos vendors que hay en el mercado. Sexto, hablar acerca del proceso de implementar una solución en self-sovereign identity. Y séptimo, sobre los retos y oportunidades de implementar esta tecnología hoy en día. Entonces, actualmente vivimos en un mundo centralizado donde toda nuestra información queda almacenada en las empresas de tecnología, usualmente las más utilizadas son Facebook, Twitter, LinkedIn, pero pueden ser también nuestros bancos, nuestros gobiernos. Y dicha información, digamos que dicha información puede ser nuestra fecha de cumpleaños, nuestra dirección, nuestra información financiera. ¿Qué pasa? Nosotros no tenemos control sobre nuestros datos y no sabemos lo que estas compañías están haciendo con nuestra información y, pues, digamos que como vimos, pues, en las últimas elecciones de Estados Unidos, no en estas, sino en las anteriores. Por favor, deben un segundo, un segundo, por favor. Un segundo. Listo. Qué pena con ustedes. Como les mencionaba, no sabemos lo que estas compañías hacen con nuestra información y esto, digamos, puede ser tan perjudicial de que puede incidir en las elecciones presidenciales de un país. Por otro lado, en este intercambio de información certificada, siempre va a haber un triángulo de confianza durante cualquier trámite o cualquier, digamos, que proceso que hagamos en nuestra vida cotidiana. Vamos a tener este triángulo de la confianza, donde en este caso hay un holder o un receptor, en este caso va a ser el ciudadano, que siempre va a recibir documentos o credenciales certificadas de su gobierno, de su universidad, de su compañía. Y estas credenciales, usualmente, las tiene que presentar ante diferentes terceros. Estos terceros pueden ser agencias de migración, pueden ser universidades, pueden ser empresas. Y en el proceso tradicional de intercambio de información, lo que pasa es que el emisor transfiere información al receptor y el verificador tiene que, de alguna forma, comunicarse con el emisor para verificar que la información que el receptor envía es completamente auténtica. Resulta que este proceso en nuestros días es totalmente ineficiente y está totalmente desactualizado. ¿Por qué? El receptor fácilmente puede manipular la información. Y si el verificador le resulta, digamos, complicado contactarse con el emisor, pues el riesgo de manipulación, adulteración de la información va a ser bastante alto. Entonces, este es el mundo centralizado en el que actualmente vivimos y esta soberanía y esta tecnología es el Sovereign Identity, lo que busca es cambiar este paradigma y empoderar a la población de sus datos. Entonces, antes de empezar a hablar de Selsovereign Identity, me gustaría hablar de un concepto del que se encuentra basado en esta tecnología que se llama zero knowledge proof. Entonces, el ejemplo para describir zero knowledge proof es un ejemplo muy americano y es cuando yo voy a un club, en Estados Unidos, yo tengo que ser mayor de 21 años y me piden el ID. Cuando me piden el ID card, usualmente en ese documento va a ir mi fotografía, mi género, si es masculino, femenino, va a ir mi dirección, va a ir mi fecha de nacimiento y van a ir otros datos que realmente no son de la competencia de la persona que me está pidiendo el ID, solamente para verificar mi edad. Entonces, lo que busca el zero knowledge proof es tu poder corroborar quién eres o qué datos necesitan sin revelar toda tu información. Sí, entonces, si yo tengo un conjunto de datos como mi fecha de cumpleaños, dirección, primer nombre, segundo nombre, género, yo solamente debo, debo, digamos, pasarle a esta persona, en este caso, al guardia de seguridad. Yo solamente, él debería saber un true or false para saber si yo soy mayor de edad o soy menor de edad, sí. Entonces, todo el concelto de la soberanidad digital gira en torno a poder intercambiar el mínimo número de información para que verifiquen la información que necesitan verificar, sí. Hay otro concepto que es muy relacionado, que se llama el data minimization principle, que lo que busca es solamente dar el número estrictamente necesario de información a quien me lo pida, sí. Entonces, para el ejemplo del club, pues claramente yo solamente tengo que dar si soy mayor o soy menor de edad, sí. Pero si yo iría a mi médico, mi médico sí necesita saber todo mi historia clínica y todas las enfermedades de pronto de las que hay sufrido. Entonces, digamos que aquí el grado de, digamos, el grado de data, el grado de acceso a la información tiene que ser mucho más alto. Entonces, el escenario ideal es yo poder controlar, digamos, que yo poder literalmente tener un termómetro y un calibrador para poder decidir qué tanto número de información quiero compartirle y a quiénes, sí. Entonces, esto, digamos, que va muy alineado con la GDPR y va muy alineado en Estados Unidos con la HIPAA, que es una agencia para, digamos, que tratar la portabilidad de información de salud. En el año 2006, este señor, Christopher Allen, a raíz de todos los problemas que ya se veían venir, los vio venir desde el 2006, donde las empresas empezarían a quedarse con grandes cantidades de información y a hacer uso, digamos, inescrupuloso de esta información. Christopher Allen propuso, en su artículo de PATHUS, Cells Over In Identity, 10 mecanismos para crear una tecnología capaz de que las personas se empoderarán de sus datos. Estos 10 principios son la existencia que los usuarios tienen que existir, que los usuarios tienen que tener control de su identidad, que los usuarios tienen que tener siempre acceso a su propia data, que siempre tiene que haber transparencia sobre los algoritmos que se están usando. Hoy en día, por ejemplo, no sabemos qué algoritmos hay detrás de Facebook, no sabemos qué algoritmos hay detrás de Twitter. Entonces, es muy bueno saber que los datos que yo estoy manejando, saber qué algoritmos están detrás de eso, que sean completamente transparentes. Es necesario que la información persista de forma permanente. Y aquí es cuando Blockchain se convierte en una excelente alternativa, porque la red de Blockchain nos permite tener alta durabilidad e inmutabilidad de la información. También el aboga sobre la portabilidad, es decir, que yo pueda llevar fácilmente mis datos y credenciales a donde yo desee. La interoperabilidad, es decir, que yo pueda demostrar quién soy a donde quiera que vaya y ante cualquier institución o persona, con sentimiento, es decir, que yo soy consciente de a quién les estoy compartiendo y a quién no les estoy compartiendo la información. El principio de minimalización, este principio se ve resumido en lo que les explicaba de zero knowledge proof, que en eso se basa gran parte de ser sobre Ignite Entity y en la protección que los derechos de todos los usuarios deben estar protegidos, ¿sí? ¿Qué pasa? Para poder cumplir todos estos conceptos, hay una tecnología que se llama Verifiable Credentials que cumple a cabalidad con todo esto. Y esta tecnología se llama Verifiable Credentials. Algo muy interesante de Verifiable Credentials y es que muchas personas, digamos que tienen esa visión errada y es que la información de las personas no se almacena en la red de blockchain, ¿sí? Porque donde la información de las personas se almacenara en la red de blockchain, esto iría en contravía de la GDPR, especialmente de la parte que dice de right to be forgotten, el derecho a ser olvidado. Entonces, es importante que la información de las personas sea cual sea, no sea almacena en la red de blockchain. Esta tecnología, digamos que tiene cuatro puntos principales y es, primero, hay que asegurar ante todo este intercambio de información cuando uno va a presentar cualquier credenciales quien emitió la credencial, ¿sí? Entonces, esto es importante para saber cuál fue el gobierno, cuál fue la universidad, cuál fue la empresa que emitió esa credencial. También para saber quién es el dueño de la credencial. Entonces, para saber quién es el dueño de la credencial, cada credencial va a tener hasta un identificador único. También estas credenciales que se pueden intercambiar, van a tener un sello de seguridad y esto se realiza mediante un firmado. Usualmente aquí hablamos de firmados típicos, puede ser incluso un firmado de RCA o puede ser un firmado con un token de JWT. Entonces, y hay otro cuarto, hay otro cuarto principio que es que no hay revocación y es que ¿qué pasa? En este tema de las verifiable credentials, cualquier emisor puede revocar una verifiable credencial en el momento que se ve y va a haber un registro público donde yo puedo ver si esa credencial fue revocada o se encuentra disponible. Esta es como la solución que se plantió siguiendo, digamos, que como respuesta a estas inquietudes que se plantió Christopher Allen en el 2006. El modelo de verifiable credentials se base en lo siguiente. Si recuerdan, y qué pena me voy a volver, si recuerdan el triángulo de la confianza, en el triángulo de la confianza el verificador tiene que ir al emisor cuando quiere verificar la información. O el receptor siempre tiene que estar como pendiente de que le van a preguntar. Lo que permite el concepto de verifiable credentials es emplear la tecnología de la cadena de bloques o blockchain para ese triángulo de la confianza, partirlo ahora en un nuevo actor que va a ser la red de blockchain. Entonces, cuando el emisor quiere emitir una credencial al receptor, es lo que hace es verificar la identidad del receptor y emitir esa credencial al receptor. Cuando el verificador va a verificar, valga la redundancia, esta información del receptor es lo que hace es verificar en la cadena de bloques. Si esa credencial fue emitida por el emisor y se encuentra firmada criptográficamente por él. Digamos que aquí no vamos a almacenar la información que él desea presentar, sino únicamente lo que él va a verificar aquí es que él exista y que eso haya sido firmado con él. De esa forma significa que el receptor sí tiene información que provino directamente del emisor. ¿Qué permite este concepto de verifiable credencials? Permite yo, bueno, el emisor emitir muchas veces a muchos holders, algo muy importante de las verifiable credencials de estas credenciales es que pueden cambiar de dueño. Entonces, un buen ejemplo puede ser, por ejemplo, la tarjeta de propiedad de un auto o, por ejemplo, podría ser la tarjeta de propiedad de una hora de arte. Podría ser un buen ejemplo. Entonces, esa tarjeta de propiedad de una hora de arte puede cambiar muchas veces de dueño y el verificador, sin importar cuál sea el dueño, va a poder verificar que esa información sí provino del emisor. Y siempre yo lo voy a poder verificar en el registro de bloques o en la blockchain. Esta verificación no tiene ningún costo. Esto es muy importante. Esta verificación no tiene ningún costo. Verificar una verifiable credencial es for free. Y emitir una verifiable credencial también es for free. No tiene costo. Este es, digamos, una visión un poco más detallada de lo que son las verifiable credencial. Entonces, aquí lo que vemos es, por ejemplo, esta es una verifiable credencial expedida. Esta es una expedida de una universidad. Sí, entonces, aquí en la universidad, siempre va a haber una parte que se llama como credencial subject. En el subject es la parte de la verifiable credencial donde yo almaceno la metadata. Esta metadata puede ser desde información universitaria, puede ser información laboral, puede ser información médica, o puede ser la información QSE. Entonces, siempre tienen en común la parte del credencial subject que, digamos, que aquí va a estar almacenado el contenido dinámico que yo quiero probar o certificar. Esto es común. ¿Quién fue el emisor? ¿Cuándo se emitió? ¿Cuándo expira? Y la parte del proof que vemos aquí es la parte como del firmado criptográfico que se le está haciendo a la credencial en el momento de la emisión. Una visión más detallada de la credencial, aquí nuevamente tenemos la fecha de emisión. ¿Quién fue el emisor? El tipo de credencial en el subject, como vemos, vemos nuevamente la metada, en este caso, relacionada a la educación. Y aquí, como ven en la prueba, estamos viendo, digamos, que este JSON, esto es un formato JSON, todo este JSON encapsulado fue firmado criptográficamente. Y esto me genera este hash descifrado que es como la prueba para que esto, digamos, ante cualquier manipulación automáticamente, según el protocolo que se está usando, esto se vea como rebocado o alterado. Las verifiable credentials tienen los siguientes componentes claves. Y hay como estos componentes que siempre debemos tener en cuenta a la hora de hablar de verifiable credentials. El primero es el dit, que son los, en español, serían los identificadores descentralizados o los descentralize identifiers. Y lo que permiten es que cada persona, objeto, empresa, tengan una identificación única en internet, ¿sí? O en la red. ¿Qué pasa? No es necesario registrar en la blockchain todos los identificadores, sino únicamente es necesario registrar los identificadores de los emisores autorizados. En este caso, los emisores autorizados van a ser los gobiernos, las universidades y las empresas. El registro de estos identificadores autorizados sí tiene un fee en la mayoría de las redes de blockchain, ¿sí? Entonces, si recuerdan, les mencioné que emitir una verifiable credential no tiene costo. Verificar no tiene costo. Sin embargo, cada vez que yo escribo en el registro de bloques sí tiene un costo. Entonces, cuando yo voy a registrar un emisor oficial, ahí sí va a haber un fee. Hay otro concepto en el mundo de la soberanidad digital o self-sovereign identity que se llama Credential Definition. Credential Definition es como el molde del tipo de credencial. Entonces, para eso les pongo los siguientes ejemplos. Para, por ejemplo, una Credential Definition de un diploma usualmente es, como ven acá, es el nombre, el nombre de la graduación. En este caso es Vashelor of Science and Arts y la fecha de grado, ¿sí? Usualmente son casi siempre dos campos. Pero, por ejemplo, podemos tener una Credential Definition para un certificado COVID, ¿sí? Y para ese certificado COVID, la Credential Definition puede tener, como campos fijos, pueden ser fecha de la primera dosis, fecha de la segunda dosis, laboratorio. Y quién fue el que, el que digamos que la entidad de salud que puso la vacuna, ¿sí? Entonces, estos Credential Definition son como los modelos de metadata que yo voy a tener. Es importante que estos Credential Definition sean públicos y sean fácilmente intercambiables entre entidades. De esa forma, todos los gobiernos o entidades van a hablar el mismo idioma y significa que, por ejemplo, en la mayoría de los ITs siempre son nombres, apellidos, fecha de nacimiento y fecha de expedición, ¿sí? Es como ponerse de acuerdo con los formatos que van a tener los diferentes tipos de documentos y acreditaciones que tienen unas personas. Esto también se tiene que escribir en la Blockchain y eso también tiene un costo. Hay otro tipo de cosa que también hay que escribir en la Blockchain y es el Revocation Registry o registro público de revocaciones. Cada vez que alguna entidad quiera revocar una creencia por diferentes causas, tiene que ir a escribir esa revocación en el registro público. De tal forma que si nos devolvemos aquí de que cuando el Verifier vaya a consultar aquí, él también tiene que hacer una validación en el Revocation Registry. Y si esta creencia le está reportada en el Revocation Registry, automáticamente va a salir que es invalida y pues lo que él está diciendo, digamos, que no se cumple, ¿sí? Esto nuevamente también tiene que ir almacenado en la red de Blockchain. Tenemos el otro concepto que ya lo expliqué antes, que es la Credential Subject, que es toda la metadata que puede ir al interior de una Verifiable Credential. Tenemos el proof que el proof es lo que es, digamos, el firmado criptográfico o el setio criptográfico que se le da a cada estructura de Verifiable Credential. Hay un concepto muy importante en este mundo de Cell Sovereign Identity, que es la Ditcom, ¿sí? La Ditcom es una red construida sobre la capa TCP y P, está en un nivel más arriba. Y lo que permite es que haya una comunicación segura entre emisores, receptores y verificadores. Lo que la Ditcom me garantiza, volviendo aquí, es que toda la información que vaya aquí viaja de forma segura, ¿sí? Entonces, si hay alguna manipulación en este canal, automáticamente el se va a dar cuenta. Si hay alguna manipulación en este canal, él se va a dar cuenta. Y de esa forma, y pedimos que haya una manipulación o fuga de datos. Este concepto, este concepto es un concepto realmente difícil de implementar. La comunidad de identidad en general tiene muchas opiniones al respecto. De hecho, hay una iniciativa que se llama Tross Over IP Foundation. Y en la Tross Over IP Foundation, lo que hace sus miembros es discutir sobre cuál es la mejor forma de implementar esta red segura dentro de la red TCP y P, ¿sí? Entonces, es realmente aquí todavía no hay un consenso. O sea, hay muchas ideas, hay algunos prototipos, pero esto todavía no es una realidad, o sea, no está live. Volviendo al tema del modelo SSI, si nosotros tuviéramos ya en nuestra wallet, en nuestro poder, un conjunto de Verifyable Credentials, nosotros seríamos los dueños de nuestra información. Y nosotros decidiríamos a quién le compartimos y a quién no le compartimos esas credenciales. En el modelo propuesto de Verifyable Credentials, con su zero knowledge proof, incluso podríamos llevar un grado de granularidad bastante, digamos que bastante detallado al punto de que, por ejemplo, yo podría saber que con mi banco solamente estoy compartiendo estos datos con la compañía de electricidad. Solamente estoy compartiendo estos datos y con Facebook solamente estoy compartiendo estos datos. Y yo perfectamente podría revocarle los permisos a esta entidad cuando quiera. Entonces, en las wallets de soberanidad digital, lo que todas las wallets tienen una sección que se llama contactos. Las contactos van a ser las conexiones autorizadas, nuevamente, las aplicaciones a las cuales yo les estoy suministrando cierta data. Pero yo nunca les sumistro toda mi data, bueno, a menos de que yo lo considere. Usualmente, la data va a ser granular. Entonces, este es el modelo de soberanidad digital. En el mundo de Hyperledger, para desarrollar esta tecnología, actualmente tenemos tres librerías o componentes principales, ¿sí? Tenemos Hyperledger Indie, que es la base y es la razón por la que estamos acá, de que exista esta tecnología parte de la base y es que nos permite manejar una identidad digital en la blockchain, ¿sí? Esa identidad digital tiene mucho que ver y pasa gracias a los dits, ¿sí? Digamos que nuestra identidad digital en los blockchain van a ser los dits. Pero hay algo muy interesante con esa identidad y es que, en vista de que uno quisiera hacer las cosas anónimamente en la blockchain, hay un concepto que se llama correlative old dits, ¿sí? ¿Qué quiere decir un correlative old identity? Y es que, por lo menos, si yo hago algo en la red de blockchain y si yo tengo un identificador, fácilmente por trazabilidad podrían llegar a mí, ¿sí? Lo que permite el cel sobre una identity es que las personas no van a almacenar sus identificadores únicos, sino que únicamente los emisores. Entonces, si alguien quiere tener trazabilidad sobre, digamos, mi identificador, mi dit, no lo va a poder hacer ya que no va a quedar registrado en la blockchain. Eso también es un concepto muy interesante que, nuevamente, se llama correlative old dits en inglés, correlación. Y es como poder, a través de algo almacenado en la blockchain, llegar al dueño de la información, ¿sí? Hay otra librería que va muy de la mano. La gente se llama URSA y URSA es un accederante con verifiable credentials. Y está el core de verifiable credentials que es hyperledded areas. Hyperledded areas, sí, está basado gran parte en verifiable credentials. Entendiendo que Digital Identity and Blockchain, si bien suena muy parecido, tiene diferencias con las verifiable credentials. Ahora, ¿qué soluciones actuales hay en el mercado? ¿O qué podemos encontrar para desarrollar este tipo de soluciones, sí? En este momento, ya hay soluciones que se han formado a base de hyperledded. Hay otras que han nacido, digamos, que basadas en otras blockchain. Voy a empezar por las de hyperledded fabric. En este caso, las que están basadas en hyperledder son principalmente sobrin, son principalmente indicio. La Canadian Credential Network. Y hay otras que están queriendo trabajar sobre sus propias blockchain, ¿sí? Un ejemplo es, por ejemplo, Doc, que está trabajando con Microsoft. Otro ejemplo es una solución de Microsoft, que se llama Ion. Está trabajando sobre, digamos, que el top of the Bitcoin, o sea, está trabajando sobre el top de Bitcoin, está trabajando sobre una capa más arriba de Bitcoin. Y Cardano también tiene su propia solución como de soberanía digital, que se llama IO Attaclaprims, ¿sí? Todas este conjunto de soluciones están para que nosotros, como developers, como desarrolladores, si queremos implementar algo donde las personas tengan soberanía, lo puedan hacer, ¿sí? Sin duda, la solución más representativa es sobrin, digamos, que es la que ha liderado por años este tema y, digamos, que actualmente gozan de una documentación bastante amplia de la cual uno podría, digamos, extenderse y desarrollar su proyecto, ¿sí? Hay muchas que, digamos, que actualmente están en prototipos. Hay otras que ya tienen testnets. Hay otras que ya tienen mainnets. Podemos encontrar soluciones de todo tipo. ¿Cuáles pueden ser ejemplos para usar estos verifiable credencias y estos conceptos que les mostré? Un buen ejemplo puede ser el COVID Credentials Initiative, que esto ya hace parte de Fundation y es la posibilidad como una Verifiable Credential, ¿sí? En este momento hay diferentes iniciativas alrededor del mundo que lo están haciendo y, digamos, que cada una tiene como que su propia solución, ¿sí? Pueden ser Verifiable Credentials, pero cada uno le añade como que su toque mágico, ¿sí? Otro caso de uso puede ser para yo verificar que yo trabajé en una empresa, que yo fui empleado de Microsoft, que yo fui empleada de Google, lo podría hacer. Otro ejemplo muy utilizado y es un ejemplo usado por Certify, es el de Proof of Studies y es poder validar la información de títulos profesionales o la información de diplomas. Otro ejemplo también podría hacer en la emisión de IDs, ¿sí? Entonces, o de licencia de conducción. Podría hacer otro ejemplo donde yo podría tener una Verifiable Credential con toda la data que contiene un ID y yo solamente comparto lo que quiero de esa Verifiable Credential. ¿Cómo hacemos si queremos implementar una solución, digamos, para cualquier área o para cualquier rama de negocio? Bueno, lo primero, esto es una recomendación. Lo primero, pues, obviamente, es tener un caso de uso, identificar un hot point o un punto clave de información segura donde yo tenga que cambiar de información segura. Y es lo más importante, donde la información de las personas, la información confidencial de las personas, sea muy sensible, ¿sí? Entonces, hay para fines médicos, para fines automotrices, para fines de obras de arte, ¿sí? Hay diferentes, digamos, mercados aún por explotar, ¿sí? El segundo paso es escoger la red de blockchain en la que la vamos a montar, ¿sí? Todo lo que esté montado, pienso, que sobre el ecosistema Hyperledger Fabric nos va a dar una garantía de que vamos a tener una excelente comunidad y una buena documentación, ¿sí? Entonces, el segundo paso sería escoger una de estas o otras más que hay en el mercado, ¿sí? Y empezar a construir la solución sobre una capa de estas. El segundo paso es, digamos, que hacer como la integración de blockchain e-house, esto, digamos, que requiere un poco más de tiempo, requiere un poco más de estudio de documentación. El segundo paso, o perdón, la tercera opción, la tercera opción puede ser hacerlo e-house o puede ser escoger un API de un vendedor, ¿sí? Entonces, ya hay soluciones que sencillamente tú tienes un API y lo que haces es integrarte y ya vuelves como que tu solución o tu wallet o lo que tú estés almacenando, lo vuelves, digamos, que orientado hacia el sobre identity. Lo tercero y para mí lo más importante es que cualquiera que sea la solución que vayas a hacer y cualquiera que sea el blockchain que vayas a escoger, fíjate que tenga una buena comunidad y una buena documentación. De esta forma, es probable que cualquier problema que te vaya a pasar, ya alguien lo vivió o si nadie le ha pasado, pues por lo menos van a haber diferentes personas tratando de remar para la misma causa. En nuestra experiencia como Certify, ¿qué desafíos hemos visto implementando self-sovereign identity? Lo primero es que los deets, que son como los identificadores únicos que se le dan a las personas, objetos, emisores, no son amigables y no tienen estructuras de tiempo, o sea, son caracteres que no son legibles para el ojumar. Y pues eso creo que en términos de implementación y de adopción de una tecnología, tiene bastante barreras. Otro desafío es que si tú quieres implementar una wallet 100% self-sovereign identity, realmente la documentación no está muy completa. Tú tienes que, digamos, que crear un agente. Usualmente estos agentes están basados en Python y en .net. Y la documentación, digamos, que no va a estar 10 de 10. Entonces ahí es cuando el tema de la comunidad se vuelve muy importante, ya que pues todos vamos a empezar a enfocarnos en lo mismo. Hay otro tema y es que son los altos fils de transacción. Y esto ya también es algo como de lo que nos ha pasado, es que, por ejemplo, nosotros iniciamos con Ethereum. Y cuando queríamos registrar cosas en Ethereum, pues los costos son absurdamente altos y las transacciones son demoradas. Y entonces es muy importante aprender a escoger muy bien sobre todas estas alternativas para que pues todo no se vaya en los transaction fees. Lo otro es la congestión de redes que va muy de la mano y es escoger como que una red que tenga como que soluciones de smart contracts o tenga soluciones extensibles. Y pues que no esté tan congestionante porque eso puede ser un tema crítico. Otro desafío que queremos es el tema de la interoperabilidad entre blockchains. Y es un tema que a mí personalmente me preocupa. Y es que ya están saliendo varios vendors ofreciendo verifiable credentials. Pero lo más importante sería en que todos tuvieran un lenguaje común para que sin importar la blockchain o el protocolo que usen se puedan entender entre ellos. Esto todavía es un tema que genera largas discusiones y todavía no hay una respuesta única. Otro desafío en torno al tema de la soberanidad digital o sell-sort-in-night-entering es lo que les mencioné al inicio de la charla y es que la gente asocial blockchain solamente con criptomonedas en la mayoría de los casos y no ve que blockchain es mucho más allá de esto, como lo pudimos ver en las slides anteriores. Lo otro que dificulta mucho la adopción de la tecnología es como la evangelización de las personas. Es en nuevamente en saberles ver que un blockchain es mucho más allá de eso. Muchas personas no saben y creo que el 70% de las personas en Latinoamérica por lo menos y no sé en España, pero creía que la cifra va a ser muy alta, pero creo que el 70, 80% de las personas no saben cuál es la diferencia entre una llave pública y una llave privada. Entonces creo que se debe educar a la población de forma general, de alguna forma para poder hacer que esta tecnología se adapte de forma mucho más rápida. Pues nada, esta fue mi presentación y espero que les haya gustado, qué pena por el ruido al principio de la charla. Y ahora pues si tienen alguna inquietud, pregunta, comentarios, súper bienvenidos. Sí, hola. ¿Se me oye? Sí. Mira, soy Juan Tabira. Veo que te has centrado la charla de SSI exclusivamente en Hyperledger y has mencionado por un momento indie y luego Fabric. Fabric lo has mencionado como red preferida para despegar la insulción de SSI y me ha resultado curioso porque Fabric tiene problemas de seguridad, las acciones no seguras dentro de Fabric, siempre hay alguna parte de la red que es capaz de conocerlas todas. Y luego veo que en lo que siempre se ha olvidado hablar de una iniciativa, esta es la más importante y además que está teniendo un gran impacto en el europeo. Lo hablas ni de Alastria, ID, ni de Epsi, ni Epsi. Sí, la conozco, digamos, que no la conozco, no la conozco en forma detallada, pero digamos que sí sé que Alastria, de hecho, es otra más de las soluciones actuales. También creo que Lachen también es otra iniciativa que también está, digamos, quedando pasos y considerables. El tema para el éxito de estas soluciones. No, que te decía que ya sé que es una charla de Hyperlegion, pero en concreto, tanto en Lachen como en Alastria, como en las redes europeas, están pasando todas en Ethereum Flavors. Me parece que es una solución bastante óptima en cuanto a la elección de red. No digo el Ethereum Mainnet, pero sí redes creadas de Ethereum por diferentes empresas sin consorción. Perdóname, soy Jorge. Muchas gracias por tu comentario. De hecho, me parece muy interesante. Solo por aclarar y por dar un poco de contexto, ¿vale? Obviamente, en el mitad de Hyperlegion, el foco está en soluciones de Hyperlegion, pero en cualquier caso, entrando un poco a la cuestión que comentabas. Existen distintas alternativas, tanto en Alastria como en Lachen como en Epsi, hay distintas soluciones tecnológicas para las redes. El hecho de utilizar o no soluciones basadas inicialmente en Ethereum no implica que no existan otras soluciones que están basadas en otro tipo de tecnologías, como pueden ser las de Hyperlegion. Yo creo que, al final, el punto más relevante quizás es uno que ya había comentado Dani anteriormente y que es la enterooperabilidad. Yo creo que más allá de la tecnología de base que se utilice en un caso muy concreto, todo este ecosistema va a poder crecer si existe la posibilidad de enterooperar entre las distintas redes y, por al ente, el que de la cuestión va más allá de la parte tecnológica que la sustente y mucho más en definiciones de estándares y en ponernos todos de acuerdo en cómo podemos colaborar a más alto nivel, como yo puedo crear un wallet que pueda interoperar con las identidades de distintas redes. Pero bueno, en cualquier caso, solo por centrarlo. Aquí, por supuesto, oiréis hablar de tecnologías ligadas a Hyperlegion. No sé si tenéis alguna otra pregunta. Borja comentaba, recalcaba un poco en el chat la importancia de la comunidad, algo más concreto, qué comunidades en particular pueden ser. Sí, ahí, ahí. Bueno, digamos, complementando, yo pienso que cada vez más están haciendo más iniciativas de soberanidad digital, digamos que a su manera, sí, pero lo más importante es, no sé, mi sueño es yo tener una wallet de cualquier vendor, yo poder hacer un export y poder hacer un import en otra wallet de otro vendor y vice versa, vice versa, poder jugar con diferentes wallets para diferentes fines. Creo que ese es el objetivo a mediano y largo plazo. Para el tema de comunidades, yo recomiendo mucho participar en un evento que se llama Identity Workshop. Se lleva dos veces al año. De hecho, la semana pasada acaba de pasar el primero de este año. En el Identity Workshop, los temas que se tratan es, digamos que, respaldados por la Linux Foundation, es como buscar cuáles son los mayores desafíos y las mejores formas de resolver temas de identidad digital y soberanidad digital. Pues también hay eventos, digamos, que otros eventos importantes de identidad. Pues también, como estamos aquí hoy, estos meetups de Hyperledger son muy productivos. También seguir muy de cerca de pronto a otras alternativas como Cardano, que está haciendo ahí otras cosas, lo que mencionaban con el tema de Tyrion ahorita. Eso es lo que les puedo decir de momento para seguir enriqueciendo el conocimiento y aportándola a la comunidad. Y, como pasos iniciales, comenta Borja con un poco más de detalle, más allá de lo que acabas de comentar, que recomendarías desde el punto de vista, por ejemplo, de lenguajes de programación, hablaste antes de Python y de .NET, que otras cosas puedan ser relevantes como conocimientos, como temas a dominar. Sí, bueno, yo creo que hay una falencia muy grave de la tecnología de SSI en general y es que los lenguajes de programación son muy limitados. Por ejemplo, aún no hay soluciones que estén 100% operativas para Node.js o para Go o para otros lenguajes. Casi todo estaba en Python, lo que comentaba, por ejemplo, de .NET. Por ejemplo, hay una gente hoy en día que es como de los más completos que hay y está en Samarin de .NET, pero opinión personal también me parece que Samarin es una tecnología no muy amigable, es muy costoso si uno quiere desarrollar una solución a gran escala. Entonces, creo que el lenguaje más importante sería como para empezar a Python. Si uno con Python podría montar su propio agente, podría conectarse, podría empezar a ser un MVP y pues ahí ya digamos que ir añadiendo, ir añadiendo le capas. Muy bien, esto bueno, te iba a hacer yo una pregunta. Si tuvieras que recomendar algunos proyectos que seguir relacionado con todo el tema que has comentado por lo novedoso que puedan estar haciendo ahora mismo o por que estén desarrollando soluciones que luego puedan ser más productivas o que puedan tener algún componente que se pueda integrar con estos tipos de soluciones, en cuáles plantarías enfocar la atención. Wow, pues la verdad eso ya es como también de gustos, pero me parece que pues tienen que tomar notas de todo lo que están aquí, aparte de alastra y del action, pues que también son muy importantes. De hecho, me gustaría proponerle a las personas que están presentes de pronto qué otro se escapa de esta lista. Por ejemplo, a mí me parece muy interesante Microsoft porque lo que están haciendo, lo están haciendo es sobre Bitcoin. Pues cualquiera pensaría que hacer una aplicación sobre Bitcoin pues no es amicable porque básicamente no permite hacer Smart Contract o ese tipo de cosas e igual lo están haciendo. Entonces, realmente nada, es como que tomen nota que por lo menos leance lo básico de cada una y pues decían con cual quieran interactuar. Por ejemplo, esta creo que si no la recomendaría, la de el que negan Crenshaw Network y la razón es por la que es muy cerrada, es algo muy cerrado, es algo ya como muy de gobierno. Vale, por añadir no es tanto una solución, pero sí lo comentaban ahora en el chat que el grupo de trabajo de identidad en HyperLayer también no es un buen entorno, es un grupo abierto, no se requiere ser software HyperLayer para poder apuntarse en este grupo y ahí aparecen también otro tipo de soluciones y aparecen también aplicaciones de esas soluciones o proyectos que se han hecho en el marco de identidad con lo cual yo creo que puede ser un buen referente también para poder identificar qué cosas están haciendo en este ámbito. Erick tenía una duda muy concreta como maneja la solución el caso de hackeo de la llave privada que firma una credencial como entiendo que en la línea de lo que comentabas de cómo se puede revocar a lo mejor una credencial que ha sido comprometido. Sí, ahí digamos que pues en caso de detectarse que hubo una credencial manipulada, sí, ahí la mejor solución y como que para ir a lo seguro es revocarla y ahí pues tiene que haber un transaction fee, o sea obligatoriamente hay que escribir algo en la blockchain y específicamente en el revocation registry, en el libro de revocaciones y pues decir que esa credencial se encuentra revocada, sí, es el mejor camino. Vale, perfecto. No sé si hay alguna o otra duda. Comenta Alfonso sobre el caso canadiense, ¿puedes desarrollar un poco Alfonso? Sí, sí, con gusto. British Columbia ha hecho un trabajo importante de canadiense, de Canadá sobrecredenciales. Y como Dani decía, que la Canadian Credential Network era algo de gobierno, sí, sí recomiendo que vean el caso de uso de British Columbia. Es importante, varias gentes, varias gentes, yo pertenezco al grupo de ID de Hyperlecher, sí, varias gentes han usado el código, el código está abierto, ahí está, pero sobre todo es una aplicación. OK, perfecto, muchas gracias Alfonso. Muy bien, pues si no hay más preguntas agradeceros a todos vuestra atención en la sesión de hoy. Muchas gracias, por supuesto, a ti por darnos esta visión durante esta tarde. Y buenos en plazo, os comento que en la próxima sesión que haremos del mitad de Hyperlecher Madrid, hablaremos de Hyperlecher Aries y en breve publicaremos el evento en la plataforma de mitad. Muchas gracias a todos por vuestra atención y esperamos veros en futuras sesiones. Muchas gracias a todos, espero que haya sido muy productiva la charla, que hayan aprendido y pues que se interesen cada vez más por este mundo de la soberanía digital. Perfecto, Dani. Gracias.