2020-05-20 Meeting notes (Arquitectura)

Date

May 20, 2020

Participants

• @Antonio Pérez Ruth

• @Héctor Insausti

• @Iñigo Garcia

• @Jaime Cuesta Tovar

• @Juan Tavira

• @Juan Luis Gozalo (Unlicensed)

• @Miguel Angel Calero Fernandez

• @Roberto García Álvarez (Unlicensed)

• @Rodrigo Lopez

• Sergio G

• @Urko Larranaga Piedra

Goals

• Revisión de las actividades realizadas durante la semana.

Discussion topics

• Track “Modelo Alastria ID - Mejoras”

  • Relación entre el TSP y el onBoarding, principalmente orientado al los DID que gestionan personas en nombre de personas jurídicas y que el onBoarding lo haga un TSP mediante el certificado digital que de delegación.

    • Se decide traspasar al Track “Modelo DID Document” que además alineará con eIDAS.

  • Credenciales PF a PF, cuando existen relaciones entre personas que no involucran a empresas. Se comenta la posibilidad de Credencial-en-Credencial o Cadenas de confianza. Trabajo en curso.

    • Credenciales anónimas. El modelo de Alatria no permite credenciales totalmente anónimas, sin embargo una entidad que aglutine o represente a otra podría emitirlas de manera general. Los TSPs podrían hacerlo por verificación de que una empresa X es del tipo Y. Pe. El banco de España podría emitir una credencial “anónima” en nombre de un banco. Queda en manos de quien quiera implementar un caso de uso.

      • Además esto entra dentro de las soluciones Zero Knowledge Proof (ZKP) que cualquier empresa podría implementar en la red Alastria.

  • Mención a “atributos temporales” vs “atributos permantenes” ej. Mayoría de edad o “carnet joven”

  • Interoperatibilidad entre redes.

    • Queda dentro del track “Modelo DID Document”

• @Antonio Pérez Ruth comenta sobre la Recuperación de la identidad. Este tema está pendiente. Es necesario establecer el modelo, algunas posibilidades:

  • Issuers de confianza que pudieran recuperar la identidad mediante reasignación del contrato proxy.

  • Dividir la clave privada en fragmentos que distribuya entre PF de confianza para posteriormente recuperarlos.

• Mapping de “campos técnicos” y “nombres amigables para el usuario”

  • Se habla de la necesidad de nombres amigables para el usuario y se desestima que sea parte de la credencial. Se comenta la necesidad de tener también un catálogo de nombres técnicos para asegurar la compatibilidad de credenciales.

    • @Antonio Pérez Ruth Comenta la existencia de https://schema.org/ y el API para consumir M2M https://schema.org/docs/developers.html como catálogo técnico. Posteriormente agrega mención a Weblate que permite en un Git colaboración en cuanto a traducciones y generación automática de ficheros de campos de usuario para aplicaciones. @María Salgado Iturrino buscará un caso de uso para ver la integración.

• Validez legal del sello de tiempo @Héctor Insausti

Action items

Decisions