2022-05-30 Meeting notes (Arquitectura)
- Juan Tavira
Date
May 30, 2022
Participants
@Daniel de la Sota Blanchart
@Rosa Prat Farrero
@Xavier Martinez
@Former user (Deleted)
@Pelayo García-Conde
@Garcia-Alvarez Roberto
@Antonio González Sanz
@Lucas Carmona Ampuero
@Manuel Gallego
@Jordi Escudero Subirana
@Alejandro Nieto Gallego
@Victoria Perez Canete
@Iker Ruiz de Infante
@Andrea Di Franco
@Carlos
@Alejandro Alfonso
Discussion topics
@Garcia-Alvarez Roberto Grupo de Liberías y Smartcontracts.
Se ha trabajado en el Credential Registry para avanzar con el nuevo modelo de anclajes
Se va a subir nueva versión en cuanto se pasen las pruebas unitarias (se están teniendo problemas)
Grupo de Schemas:
No hubo reunión. No hay de momento novedades. Como hay nueva documentación nueva de EBSI se va a tratar para tenerlo en cuenta.
@Carlos presenta los anclajes:
Anclaje de credenciales: Se ha trabajado solo en las de emisión. La idea principal y la que está
llevando Europa es la de mantener al mínimo los anclajes. Se dotará a los SC de la capacidad de permitir
estos anclajes pero no se exige.
Anclaje de presentaciones: Igualmente será opcional para el usuario el anclaje de la presentación,
habiendo una recomendación de que esta presentación no podrá ser borrada y dejando claro al usuario
que este anclaje es opcional. Si el usuario decide anclar la presentación (no sin antes haberle advertido,
aunque sea repetitivo) el Service Provider debería tambien anclar la recepción de la presentación.
Se hace votación para la aceptación de los anclajes por el grupo de arquitectura. Se acepta por
falta de opiniones en contra. A Alejandro y Dani están a favor. No hay más comentarios.
El objetivo es enfatizar que los anclajes son opcionales, manteniendo los casos simples y sin complicar el protocolo.
Anclajes relativos a la emisión y recepción inicial de las credenciales:
Conclusión propuesta:
El emisor puede anclar la emisión (en estado Valid) si cree que tiene base legitimadora para hacerlo. No se presume que haya consentimiento implícito del usuario por usar el modelo Alastria ID.
El usuario puede anclar la recepción (en estado Valid) si lo decide libremente, por defecto no se debe anclar a no ser que el usuario seleccione activamente y de manera informada la opción de anclaje de la recepción.
No añadimos en los mensajes, objetos ni artefactos del protocolo la posibilidad de pedir al usuario que ancle la recepción de la credencial.
El resto de los anclajes a los estados AskIssuer, Revoked, DeletedBySubject no se modifican, se están adaptando los Smart Contract para V2.1 para asegurar que se pueden alcanzar directamente estos estados sin haber pasado por el estado Valid, tanto para Issuer como para subject.
@Garcia-Alvarez Roberto Manda el link a la nueva documentación de EBSI:
Carlos propone que la documentación se revise esta semana por cada uno de nosotros para que el lunes que viene se pongan en común las dudas que se tenga.
Alejandro y Dani proponen que en el equipo de esquemas también se revise ya que puede tener impacto.