/
2022-10-17 Meeting notes (Arquitectura)

2022-10-17 Meeting notes (Arquitectura)

Date

Oct 17, 2022

 

Participants

@Juan Tavira

@Former user (Deleted)

@Andrea Di Franco

@Antonio González Sanz

@Garcia-Alvarez Roberto

@Alejandro Alfonso

@jordi.escudero

@Manuel Gallego Chinchilla

@Carlos Pastor Matut

@Iker Ruiz de Infante Gonzalez

@Miguel Angel Calero Fernandez

@Marta Lobera

 

 

Discussion topics

 

Grupo Librerías y Smartcontracts: @Garcia-Alvarez Roberto

Victor Nieves deja de liderar el grupo de librerías y desarrollo y lo llevará ahora @Garcia-Alvarez Roberto No hubo reunión pero se avanzó en los siguientes puntos:

  • Despliegue de SmartContracts v2.1 (opcional el anclaje de credenciales y presentaciones). Hay que eliminar de los examples los casos que ya no tienen lógica. Manuel está creando un nuevo example de credenciales y si funciona hacer lo mismo del de presentaciones y cuando funcionen ya tendríamos la v2.1 para liberar.

  • El proceso de cambiar las líneas del package JSON para probar las nuevas ramas están dando un fallo de npm y se necesita alguien que pueda ayudar para corregirlo. El "npm install" lo hace siempre de la rama master.

Se hace llamada a los presentes para ver si alguien puede aportar algún desarrollador a tiempo parcial para el equipo.

 

Grupo de Schemas: @Alejandro Alfonso

El jueves hubo reunión (sólo digitel y fiware), se revisó el repositorio, hay esquemas de EBSI que han quedado descontinuados y se han archivado. Se establecen los schemas de FIWARE para persona física. Estos schemas están en formato JSON-LD que se pueden extender fácilmente. Llamada a colaboradores.

Se desarrollarán librerías para comprobar que los objetos cumplen los schemas.

Llamada a colaboradores que sepan desarrollar en javascript/typescript.

 

Novedades en Europa: @Carlos Pastor Matut

EBSI: Sigue el proceso de definición de la definición de las redes de los 3 entornos: piloto, pre, prod. Se ha clarificado qué es cada uno y cuales son los SLAs de las redes y sus consecuencias. Se está trabajando en la parte legal y técnica de despliegue. El entorno piloto se borrará una vez al año. La posición de la comisión es que la comisión no quiere responsabilidad sobre la operación, se delega en los estados miembros (lo que hace ahora lo hace en nombre de los estados miembros).

 

Discusión general de arquitectura:

@Juan Tavira Comenta cambios y mejoras en el modelo de EPIC.

  1. Se crea una definición de patrones de derivación para que las derivaciones que tengan partes de diversa cardinalidad queden bien definidas.

  2. Se explica la nueva ordenación de las derivaciones. Con objeto de hacer la identidad más interoperable las derivaciones que se refieren a Main Entity, Network, Network Specific pasan a estar por debajo del wallet. Se renombran algunas derivaciones. Se añaden los niveles de derivación de seguridad por encima del wallet.

  3. Se explica que hay una rama del código donde se está realizando el trabajo de la rotación de claves.

 

Se abren diversas discusiones con @Juan Tavira @Carlos Pastor Matut @Alejandro Alfonso @Manuel Gallego Chinchilla.

  1. ¿Se puede hacer que una revocación de nivel B invalide las credenciales? Este tema sale por la explicación del modelo de rotación de una clave a nivel B. Debería ser lo normal, si por seguridad se rota la derivación B todas las credenciales emitidas en esa derivación deberían quedar invalidadas. PTE de revisión técnica.

  2. Como originalmente la rotación B era por un tema de seguridad preventiva en cuanto al login y para evitar que un cambio de B afecte a todas las credenciales (tal cual se explica en el punto anterior) se plantea que las rotaciones de B puedan ser invalidantes o no. Resulta un poco confuso y se propone que el login no sea únicamente realizado con la derivación “B/0” si no con “B/0/D*” y que se pueda rotar D* por prevención no afecta a las credenciales que han sido emitidas en derivaciones “B/1/…”. PTE de revisión técnica.

  3. Rotaciones a nivel “W”. Estas son las más complejas porque presupone que se ha producido un problema de seguridad en el Wallet. Hay varios temas a tratar:

    1. No se deberían almacenar las derivaciones R y SSSSS en el wallet. Si se almacenan comprometer el wallet sería comprometer toda la identidad y no se podría recuperar. El objetivo sería usar “R/SSSSS/W” para generar W y luego guardar “R/SSSSS/W” fuera del wallet (quizá mediante un método de compartir secretos tipo Shamir) y borrar ese dato del wallet.

    2. La rotación de W sería:

      1. Demostrar la posesión de R y W antiguo mediante la exposición de ExtPubK a nivel R y ver que la derivación SSSSS/W genera la ExtPubKey a nivel W.

      2. Firmar una transacción con R para demostrar la posesión de la clave privada.

      3. Generar un nuevo par de claves a nivel W con R/S’S’S’S’S'/W' y pedir al usuario que guarde “R/S’S’S’S’S'/W'“ fuera del wallet.

      4. PTE de revisión técnica.

 

 

Se adjunta la PPT de trabajo sobre la que se ha discutido, sólo tiene actualizadas las slides de patrón de derivaciones y nomenclatura de derivaciones. Es necesario actualizar el árbol de derivaciones para adecuarse a la nueva nomenclatura y orden.

 

 

Se recuerda que la sesión del 24 será de corta duración.