2022-02-14 Meeting notes (Arquitectura)

Date

Feb 14, 2022

 

Participants

@Juan Tavira

@Antonio Pérez Ruth

@Miguel Angel Calero Fernandez

@Antonio González Sanz

@Garcia-Alvarez Roberto

@Alejandro Alfonso

@Alexander Herranz

@Alejandro Cuenca Parra

@Carlos

@Xavier Martinez

 

Discussion topics

 

@Garcia-Alvarez Roberto Informa que la semana pasada no ha habido avances en el grupo de liberías y smartcontracts pero que tienen en la agenda una sesión de trabajo para el día 17 de 17 a 18 horas.

@Carlos Informa que @Jesús Ruiz nos contará sus ideas de identidad en las que no se ancla el DID en la red.

@Carlos Informa de los avances en EBSI. Se busca no anclar el DID sino el DID document pero en vez de hacerlo en claro usando una firma del mismo y luego se inserta únicamente el hash el documento firmado. Además se indica que se usarán varias firmas asociadas al mismo DID: para control del DID, para firma de presentaciones y para autenticar al usuario. El DID document, firmado o una parte del mismo (recomendación de @Carlos en EBSI, por ejemplo sólo la clave de firma cuando firmemos objetos y sólo la de autenticación cuando sea autenticación) sería necesario entregarlo con las presentaciones (o previamente) para poder validarlas. Además habría que comprobar la cuenta con la que se ha escrito el hash del DID document para garantizar la autenticidad y eso podría poner a la firma de control del DID document en una situación de convertirse en dato pseudónimo, aunque improbable por la baja actividad de esta cuenta. En EBSI están buscando modificar al mínimo su modelo, pero aún no han tenido en cuenta la complejidad de la rotación de claves. @Miguel Angel Calero Fernandez pregunta cuando sería necesario anclar el DID document (o su hash) y parece ser que si se trata de claves derivadas al estilo HD Wallet sólo sería necesario cuando se haga rotación de claves. El DID sería la dirección Ethereum o algo derivado de la clave pública.

También se discute de la necesidad de crear dentro de la comisión de Identidad un grupo de schemas de credenciales. Se piden voluntarios para dirigirlo y para participar en él. El objetivo del grupo es llevar la organización y control de los schemas de credenciales que se utilicen en Alastria. Se crearía un repositorio de credenciales, este grupo controlaría las issues para publicar nuevas credenciales o modificaciones de las existentes. La idea subyacente es la de reutilizar al máximo los schemas de credenciales y mejorarlos con atributos opcionales siempre que sea útil.

@Carlos apunta que @Jesús Ruiz querría participar en el grupo aunque no liderarlo y que además de basarnos en los schemas existentes de la W3C y EBSI podríamos también fijarnos en FIWARE. En EBSI por ejemplo ya hay algunos ejemplos de credenciales core de identidad y de diplomas.

Finalmente @Juan Tavira y @Carlos repasan la explicación de HD Wallets de la sesión anterior, explicando que no está cerrado que los HD Wallets puedan cumplir con la Cadena de confianza para derivaciones que incluyan tanto clave pública como privada. Esto está en estudio. Se recomienda la visualización del video https://www.youtube.com/watch?v=2HrMlVr1QX8&t=5s muy ilustrativo de los HD Wallets.

En conversación posterior @Juan Tavira intentará contactar con Weblate para la licencia de traducción de términos técnicos de las credenciales a diferentes idiomas.