2022-01-24 Meeting notes (Arquitectura)

Date

Jan 24, 2022

Participants

@Juan Tavira

@Garcia-Alvarez Roberto

@Ivan Moreno

@Xavier Martinez

@Nacho Alamillo

@Alejandro Alfonso

@Antonio González Sanz

@Javier Bernal

@Alejando Cuenca

@Carlos

@Iñigo Garcia

@Antonio Pérez Ruth

@Urko Larranaga Piedra

Discussion topics

• Recordatorio del plan actual: evolucionar la identidad para alinearnos con lo comentado en la reunión anterior (2022-01-17 Meeting notes (Arquitectura) )

• Se abre la posibilidad de comentar posibles ideas:

  • @Iñigo Garcia comenta:

    • Meter el estado de los objetos en los propios objetos y publicar únicamente el hash del elemento+estado

    • Evitar el anclaje del DID en la red, relacionar el DID y su clave pública, firmarlo y hashearlo y pasar el dato en el objecto para poder verificar la integridad de todo.

  • @Carlos y @Nacho Alamillo comentan que han estado revisando y formalizando el algoritmo de firmado de una presentación (se añadirá al acta una versión definitiva cuando esté finalizada)

  • @Juan Tavira presenta un modelo titulado “Alastria E.P.I.C” (Enhanced Privacy Identity Concept) basado en:

    • Eliminación del anclaje del DID en la red

    • Creación del concepto de Cadena de confianza de DIDs

    • Incluir la clave pública en los objetos que requieran validación

    • Evitar el uso del DID como índice en los registry de Credenciales y Presentaciones

•  

• Open

  

   

Open

Se comentan los siguientes aspectos:

• Cadena de confianza (Chain of Trust): la definición actual no es más que una firma cruzada, no evita que dos usuarios se pongan de acuerdo en enlazar sus identidades (para ello deberán tener acceso a las claves privadas del otro usuario, puede ser válido si hay la premisa de que no se pueda sacar la PrivK del dispositivo).

  • La cadena de confianza debería tener una credencial de identidad común para ambos DIDs que permita verificar que es el mismo Subject para poder usarlo en el modelo “late binding” que es Alastria ID con SSI (vs modelos “early binding” como es eIDAS)

  • Se podría usar un sistema de claves derivadas, quizá de un nemónico, para enlazar los DIDs

• El modelo de que la revocación se base en un hash que constituye un secreto entre dos partes parece débil, debería haber más seguridad como que el msg.sender deba coindicir con el DID del objecto a revocar.

Decisions

1. Los asistentes seguirán buscando alternativas al modelo y soluciones a los problemas del presentado Alastria EPIC.

2.