30/09/2022 - Meeting Notes Libs
- Garcia-Alvarez Roberto
Asistentes
En presencial
@Garcia-Alvarez Roberto
@Juan Tavira
@Antonio González Sanz
@Carlos Pastor Matut
@Iñigo Garcia
@Alejandro Alfonso
@Alejandro Nieto Gallego
@Daniel de la Sota Blanchart
@Patricia
En remoto
@Former user (Deleted)
@Manuel Gallego Chinchilla
@Juan Tavira realizó un repaso de EPIC, y una demo de la parte de presentaciones en la que entró en más detalle. También se tratarón otros temas como los mencionados en la sección de “OTROS PUNTOS TRATADOS“.
PUNTOS DEL DÍA:
Z0 -> Los cuatro primeros niveles de derivación son fijos.
A0/A -> Los siguientes dos niveles son de identidad del usuario. El primero de ellos para la recuperación y el segundo de ellos para la rotación de identidad.
Los cuatro niveles siguientes son:
B -> La entidad con la que se relaciona el usuario (Este nivel las entidades no lo tienen)
C -> Propósito (0/login, 1/credencial, 2/presentación)
D -> Dos niveles D para indicar el propósito de las derivaciones
E -> Este nivel lo marca la entidad, para evitar la suplantación de identidad. Queda a elección de la entidad que pueda indicar al usuario más de un nivel E, dependiendo de la seguridad que le quiera dar a dicha derivación.
Explicación del ejemplo de presentaciones:
La primera acción a realizar es la creación del wallet al usuario, setear el mnemónico y calcular la derivación de identidad con los dos últimos niveles completamente diferentes al resto de wallets y la derivación que asigna la etidad en cuestión.
Crear el wallet para la entidad con su derivación de identidad y la derivacón de nivel C para el usuario.
El emisor de las credenciales emite las credenciales a diferentes identidades(diferentes DIDs) que se las ha proporcionado previamente el usuario.
El SP se crear el wallet de la misma manera que el emisor.
El usuario asigna otra derivación diferente para hablar con el SP. El usuario le dice al SP cuál es la clave pública para hablar con él.
El usuario se guarda para el SP las tres claves públicas, la de login, la de credenciales y la de presentaiones.
Las derivaciones D las marca el usuario y la derivación E la marca el SP para cada una de las presentaciones que haga este usuario.
Posteriormente el usuario genera la información necesaria para demostrar que las credenciales que contiene la presentación son suyas. ChainOfTrust.
Se hacen dos verificaciones, la verificación de la firma de la presentación y la verificación de la ChainOfTrust.
Siempre que se pueda, se ha llegado a la conclusión de que es más seguro pasar las derivaciones y que la entidad genere las claves públicas asociadas a esas derivaciones que pasar las claves públicas en sí.
OTROS PUNTOS TRATADOS:
Como con este modelo se crean identidades por cada entidad para los sujetos, se puede revocar la identidad que has entregado a cierta entidad por cualquier motivo y de esta manera no hay que revocar la raiz de la identidad.
Se podría unificar todo en un único registry y así conseguiríamos más entropía porque no se sabe de que objeto se estaria hablando, si de credenicales, presentaciones, etc. ya que lo que se registra serían hashes de credenciales, presentaciones, etc. (reunión arquitectura para tomar una decisión de si lo unificamos en un único Smart Contract los registrys que hay en el modelo de identidad de Alastria)
Las claves públicas de la entidad irían al AlastriaNameServices. (reunión arquitectura)
Por otro lado, el registro que se realizaría en blockchain de los hashes de las credenciales y presentaciones, se propone que sea la concatenación de los objetos(credenciales y presentaciones) con el estado, aunque las consultas se complicarían un poco. Actualmente se está registrando el hash y el estado en claro por separado(reunión arquitectura)