ES2984852T3

ES2984852T3 - Emisión de credencial digital verificable

Info

Publication number: ES2984852T3
Application number: ES22173852T
Authority: ES
Inventors: Paul Bastian; Micha Kraus; Jörg Fischer
Original assignee: Bundesdruckerei GmbH
Current assignee: Bundesdruckerei GmbH
Priority date: 2021-05-17
Filing date: 2022-05-17
Publication date: 2024-10-31
Anticipated expiration: 2042-05-17
Also published as: PL4092958T3; DE102021112754A1; EP4092958A1; EP4092958B1

Abstract

La invención se refiere a un método para leer uno o más atributos de usuario (206) de un token de identificación (200) utilizando un sistema informático de proveedor de identificación (500) de un servicio de proveedor de identificación y para proporcionar una credencial verificable digital con los atributos de usuario leídos (206) en una billetera de identificación digital (102) de un terminal móvil (100) utilizando un sistema informático de emisor (300) de un servicio de emisor de una infraestructura SSI. Los atributos de usuario (206) de un usuario (10) se almacenan en un área de memoria protegida (204) de una memoria (202) del token de identificación (200). La infraestructura SSI comprende una cadena de bloques (400) en la que se almacenan un esquema de datos (406) para la credencial verificable digital y una clave criptográfica pública (318, 404) asignada al servicio de emisor. El esquema de datos (406) sirve como plantilla para verificar la credencial verificable digital. La clave criptográfica pública (318, 404) del servicio emisor sirve como clave de verificación de firma para comprobar una firma de la credencial digital verificable, que se crea con una clave criptográfica privada (322) del servicio emisor asignada a la clave de verificación de firma como clave de firma. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Emisión de credencial digital verificable

La invención se refiere a un método para emitir una credencial digital verificable utilizando atributos de usuario proporcionados por un token de ID. La invención se refiere además a un terminal móvil, un sistema informático emisor y un sistema para emitir una credencial digital verificable utilizando atributos de usuario proporcionados por un token de ID.

En un mundo cada vez más conectado, las identidades digitales seguras, así como las pruebas digitales verificables y, por tanto, fiables, de las identidades correspondientes son cada vez más importantes. Las identidades digitales, por ejemplo, son un requisito previo para diseñar eficazmente procesos comerciales digitales, flujos de trabajo digitales y sistemas técnicos. Al mismo tiempo, las identidades digitales, como datos personales de los titulares de las correspondientes identidades, representan un activo sensible y vulnerable.

Para que las identidades digitales exploten realmente su potencial para respaldar procesos comerciales digitales, flujos de trabajo digitales y sistemas técnicos, es necesario un alto nivel de aceptación por parte de los usuarios. Para lograr un nivel tan alto de aceptación por parte de los usuarios, es necesario que, por un lado, las identidades digitales respeten la privacidad de sus titulares y sean capaces de garantizar su protección de forma segura, pero, por otro lado, también sean sencillos y fáciles de manejar. Si bien protocolos como TCP/IP o HTTP se han consolidado a largo plazo en algunos ámbitos gracias a la digitalización, en el ámbito de las identidades digitales todavía faltan estándares comparables. Desde los primeros días de Internet, no se ha establecido ningún estándar global para la identificación y autenticación.

La falta de pruebas digitales generalmente aceptadas para la identificación y autenticación de los usuarios representa uno de los mayores obstáculos para la digitalización. Lo que se necesita es un enfoque de las identidades digitales que permita un intercambio fluido, seguro y con pocos datos de diferentes pruebas digitales. Los documentos US2020/259656, "Distributed-Ledger-based Authentication with Decentralized Identifiers and Verifiable Credentials"de Zoltan Andras Lux et al. y EP3318999 forman parte del estado de la técnica.

Por lo tanto, la invención se basa en el objetivo de proporcionar un método para la emisión de credenciales digitales verificables, que sea seguro y fácil de manejar.

El objetivo en el que se basa la invención se resuelve con las características de las reivindicaciones independientes de la patente. Las formas de realización de la invención se exponen en las reivindicaciones dependientes de la patente.

Las formas de realización comprenden un método para leer uno o más atributos de usuario de un token de ID usando un sistema informático proveedor de ID de un servicio proveedor de ID y proporcionar una credencial digital verificable con los atributos de usuario leídos en una cartera de identificación digital de un terminal móvil usando un sistema informático emisor de un servicio emisor de una infraestructura SSI,

en el que los atributos de usuario de un usuario se almacenan en un área de memoria protegida de una memoria del token de ID,

en el que la infraestructura SSI comprende una cadena de bloques en la que se almacenan un esquema de datos para la credencial digital verificable y una clave criptográfica pública asignada al servicio emisor, sirviendo el esquema de datos como plantilla para verificar la credencial digital verificable, utilizándose la clave criptográfica pública del servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave criptográfica privada del servicio emisor asignada a la clave de verificación de firma como clave de firma,

comprendiendo el método:

• el envío de una solicitud de emisión para emitir la credencial digital verificable desde el terminal móvil a través de una red al sistema informático emisor para iniciar una lectura de los atributos del usuario por parte del sistema informático proveedor de ID desde el token de ID,

• la concesión de acceso de lectura del sistema informático proveedor de ID a los atributos de usuario en el token de ID a través del terminal móvil y la red para reenviar los atributos de usuario leídos al sistema informático emisor,

• la recepción de la credencial digital verificable emitida por el servicio emisor a través de la cartera de identificación digital del terminal móvil desde el sistema informático emisor a través de la red, construyéndose la credencial digital verificable de acuerdo con el esquema de datos proporcionado en la cadena de bloques, que comprende los atributos de usuario leídos, y utilizando la clave de firma del servicio emisor,

• el almacenamiento de la credencial digital verificable recibida en la cartera de identificación del terminal móvil.

Las formas de realización pueden tener la ventaja de que se puede implementar un ecosistema descentralizado de identidades digitales basado en los principios de la Identidad Autosoberana (SSI). Las identidades digitales correspondientes se pueden implementar en forma de credenciales digitales verificables basadas en un token de ID, en particular en un token de ID en forma de un documento oficial, como, por ejemplo, un documento de identidad electrónico, un pasaporte electrónico y/o un carné de conducir electrónico. Los datos de identidad en forma de atributos de usuario pueden leerse de forma segura y sencilla desde un token de ID correspondiente y almacenarse como una credencial digital verificable en un programa de cartera o una cartera de identificación en un terminal móvil, como un teléfono inteligente. El terminal móvil puede utilizar las credenciales digitales verificables almacenadas sin que sea necesario el token de ID. Del mismo modo, para utilizar los atributos de usuario en forma de credencial digital verificable, no es necesaria una lectura adicional del token de ID ni una mayor integración del sistema informático proveedor de identificación. Más bien, el terminal móvil con la cartera de identificación puede ser suficiente para que el usuario utilice la credencial digital verificable basada en la infraestructura SSI.

Una vez que los atributos del usuario se han almacenado en el terminal móvil en forma de credencial digital verificable, se pueden utilizar con el terminal móvil sin que el usuario necesite dispositivos técnicos adicionales. De esta manera, el uso de los atributos del usuario es simple y fácil.

Un destinatario comprueba la validez de una credencial digital verificable correspondiente proporcionada por el terminal móvil, es decir, la verifica, como verificador utilizando la infraestructura SSI. Para ello, el verificador utiliza, por ejemplo, la infraestructura SSI, que comprende una cadena de bloques que proporciona al verificador los datos necesarios para la verificación.

Las credenciales digitales verificables y, por tanto, los atributos del usuario se pueden almacenar de forma segura en el terminal móvil. Para ello, las correspondientes credenciales digitales verificables se almacenan en la cartera de identificación o en un área de memoria protegida de una memoria del terminal móvil asignada a la cartera de identificación. En particular, almacenar credenciales digitales verificables en la cartera de identificación del terminal móvil permite que las credenciales correspondientes se utilicen varias veces para identificar de forma segura al usuario del terminal móvil ante terceros.

Las formas de realización pueden tener la ventaja de que se puede proporcionar de manera eficaz y eficiente la emisión de credenciales digitales verificables basadas en una infraestructura SSI en combinación con una infraestructura para la lectura segura de atributos de usuario a partir de tokens de ID. Existe una estrecha conexión entre el sistema informático emisor y el sistema informático proveedor de identificación. Por ejemplo, un sistema informático emisor comprende un programa de utilidad("eService")para iniciar la lectura de los atributos del usuario utilizando el sistema informático proveedor de ID. Para ello, el programa de utilidad del sistema informático emisor proporciona al terminal móvil o a un programa cliente incluido en el terminal móvil los datos necesarios para iniciar el proceso de lectura. Por ejemplo, los datos correspondientes son datos que se proporcionan en forma de URL ("Uniform Resource Locator')que permite que el programa cliente se comunique con el sistema informático proveedor de ID para leer los atributos de usuario solicitados. Los atributos de usuario leídos de esta manera son utilizados por el sistema informático emisor para emitir una credencial digital verificable, que se almacena en la cartera de identificación del terminal móvil. Por lo tanto, la credencial digital verificable emitida se basa en atributos de usuario específicos del usuario, que se toman de un documento o token de ID del usuario.

Por ejemplo, entre la cartera de identificación y el programa emisor puede establecerse inicialmente un canal de comunicación cifrado, en el que se realiza una autentificación mutua entre la cartera de identificación y el programa emisor. Esto significa que se puede garantizar al inicio del procedimiento entre qué partes se inicia el procedimiento y a quién se enviará al final la credencial digital verificable emitida. Además, al integrar el servicio proveedor de ID o la funcionalidad del sistema informático proveedor de identificación en el servicio emisor o en el sistema informático emisor, se permite configurar un canal de comunicación cifrado para leer los datos del usuario dentro de un canal de comunicación cifrado previamente configurado entre la cartera de identificación y el sistema informático emisor. Para ello, el sistema informático emisor comprende, por ejemplo, un programa proveedor de ID configurado para leer atributos de usuario. De este modo, el canal de lectura correspondiente puede ser tunelizado a través del canal a través del cual se proporciona la credencial digital verificable y que se basa en la autenticación mutua de los participantes. De este modo se puede garantizar que la lectura se realice a través del mismo terminal móvil, en particular a través de la misma cartera de identificación, en la que posteriormente se inserta la credencial digital verificable.

Finalmente, las formas de realización pueden tener la ventaja de que el material de clave se puede almacenar de forma segura en un elemento de seguridad del terminal móvil, como un teléfono inteligente. Por ejemplo, el material de clave correspondiente se almacena en un elemento de seguridad o utilizando un elemento de seguridad implementado en forma de un elemento seguro (SE), una eSIM, un elUCC y/o un TEE. El material de clave correspondiente se utiliza, por ejemplo, en la cartera de identificación para el almacenamiento criptográficamente seguro de credenciales digitales verificables. Por ejemplo, las credenciales digitales verificables se cifran utilizando el material de la clave y se almacenan de forma cifrada en el área de memoria protegida del terminal móvil.

Las formas de realización pueden tener la ventaja de que se habilita una transferencia segura de datos de identidad en forma de atributos de usuario desde un token de ID a una cartera de identificación de un terminal móvil cargando los atributos de usuario en forma de credencial digital verificable en la cartera de identificación. Ya no es necesario un proveedor de identificación para seguir usando la credencial digital verificable. Además, no es necesario ningún otro programa informático. Más bien, el usuario puede utilizar la credencial digital verificable únicamente en función del terminal móvil con la cartera de identificación.

Según formas de realización, por ejemplo, se proporciona un servicio emisor que, basado en una infraestructura SSI, permite la transmisión segura de atributos de usuario desde un token de ID y la emisión de una credencial digital verificable en una cartera de identificación.

Las identidades autodeterminadas (“Self-Sovereign Identityo SSI) se refieren a identidades de una infraestructura de identidad descentralizada y centrada en el usuario, que permite que un usuario reciba una identidad distribuida, autodeterminada, segura y que proteja la privacidad.

Los principios básicos de SSI comprenden: existencia (“existence"),control (“control’), acceso(“access"),transparencia (“transparency),persistencia (“persistence"),portabilidad(“ portability’),interoperabilidad(“interoperability’),consentimiento(“consent’),minimización (“minimalization"),protección (“protection").El principio básico de existencia requiere que cada usuario individual tenga una identidad independiente. El principio básico de control requiere que los usuarios controlen sus respectivas identidades. El principio básico de acceso requiere que cada usuario tenga acceso a sus propios datos. El principio básico de transparencia requiere que los sistemas y algoritmos sean transparentes. El principio básico de persistencia requiere que las identidades sean duraderas. El principio básico de portabilidad requiere que la información y los servicios de identidad sean portables. El principio básico de interoperabilidad requiere que las identidades sean utilizables en la medida de lo posible. El principio básico del consentimiento requiere que los usuarios acepten el uso de su identidad. El principio básico de minimización requiere que se minimice la divulgación de afirmaciones(“claims"),como los atributos del usuario. El principio básico de protección requiere que se protejan los derechos del usuario.

Al poner las identidades y su uso en manos de los usuarios, una infraestructura SSI no comprende un papel central, como el de un proveedor de identidad, que participa en cada proceso de autenticación, es decir, en cada uso de los atributos del usuario, y, por lo tanto, es omnisciente sobre las actividades que el usuario conoce. En el presente caso, por ejemplo, un proveedor de identidad solo se utiliza para emitir credenciales digitales verificables, pero no para utilizarlas. Esto significa que el proveedor de identidad no tiene conocimiento del uso de los atributos de usuario correspondientes. Lo mismo se aplica a los sistemas informáticos emisores que emiten las correspondientes credenciales digitales verificables. Estos tampoco participan en el uso de los atributos del usuario ni en la verificación de las credenciales digitales verificables que emiten. Más bien, la verificación la lleva a cabo un verificador independiente que utiliza una cadena de bloques de la infraestructura SSI. Por lo tanto, los sistemas informáticos emisores no tienen conocimiento del uso de los atributos del usuario.

La cadena de bloques correspondiente implementa la infraestructura SSI mediante tecnología de contabilidad distribuida (DLT), que proporciona un almacenamiento descentralizado y de acceso público para los datos de verificación en forma de cadena de bloques, que, por ejemplo, también puede garantizar la privacidad de los usuarios.

En un triángulo SSI, que describe la emisión y el uso de una credencial digital verificable, se definen tres roles: emisor(“issuer’),titular(“holder’)y verificador(“verifier’).El titular gestiona varias credenciales digitales verificables en una cartera digital owalletvirtual. Estas credenciales son emitidas por uno o más emisores y generalmente contienen declaraciones(“claims")sobre el titular o usuario, como nombre, dirección, nacionalidad y/o fecha de nacimiento. Estas declaraciones sobre el titular o los atributos del usuario correspondiente se denominan atributos de usuario, es decir, atributos asignados al usuario.

El titular puede, por ejemplo, disponer de una pluralidad de diferentes credenciales digitales verificables con diferentes atributos de usuario. Esto permite al titular decidir por sí mismo qué atributos de usuario envía a un verificador para su verificación. El verificador puede garantizar la autenticidad y la infalsificabilidad de las credenciales digitales verificables transmitidas y, por tanto, de los atributos de usuario proporcionados, basándose en datos de verificación pública, que son proporcionados, por ejemplo, por una cadena de bloques. Los datos de verificación pueden ser proporcionados por una infraestructura descentralizada basada en una cadena de bloques o un registro distribuido(“distributed ledger’)del ecosistema SSI. Además de información sobre la identidad del emisor y el esquema de credenciales, los datos de verificación también pueden incluir información sobre, por ejemplo, credenciales revocadas. Por ejemplo, los datos de la verificación no comprenden ningún dato personal del titular de las credenciales digitales verificables. Esto significa que ningún dato personal tiene que estar ni estará disponible públicamente. De este modo, el proceso de emisión puede desacoplarse del proceso de autenticación, ya que no es necesario ningún contacto con el emisor para la verificación. Como es habitual en el mundo analógico, el emisor de la identificación no aprende nada sobre su uso, lo que representa una contribución importante a la autodeterminación de los usuarios y a garantizar su privacidad.

A diferencia del proceso analógico, al utilizar SSI se pueden utilizar mecanismos adicionales, en particular mecanismos implementados técnicamente para respaldar la privacidad de los titulares de las credenciales digitales verificables. Por ejemplo, la minimización de datos se puede promover mediante la divulgación selectiva de declaraciones o atributos de usuario de una credencial digital verificable o declaraciones lógicas sobre los atributos de usuario correspondientes. Por ejemplo, para verificar la edad, se puede proporcionar una declaración lógica "mayor de 18" en lugar de una fecha de nacimiento específica del titular. Con SSI, por ejemplo, la divulgación de los atributos del usuario se puede implementar con una prueba criptográfica interactiva, de modo que a menudo se hace referencia al titular como "verificador". Por ejemplo, con cada conexión con una entidad, un titular puede aparecer bajo un nuevo seudónimo, de modo que solo tenga que revelar todo lo necesario y lo menos posible sobre sí mismo, dificultando así la trazabilidad no deseada. El mayor control y transparencia posibles sobre los datos genera confianza entre los usuarios y puede aumentar su aceptación de los procedimientos basados en SSI. La portabilidad y la interoperabilidad aseguradas mediante estándares abiertos pueden, por ejemplo, garantizar la preservación a largo plazo de un ecosistema SSI.

SSI también puede aportar un valor añadido a las empresas o a la administración pública mediante la creación de un estándar uniforme para el intercambio de información de identidad, que ofrece una infraestructura común, distribuida y, por tanto, a prueba de fallos y garantiza una verificación sencilla y segura de los datos sin tener que contactar uno mismo con el emisor de las credenciales digitales verificables utilizadas para este fin. Esto permite, por ejemplo, acelerar el procesamiento de información de identidad en forma de las correspondientes credenciales digitales verificables, ya que a través de una interfaz se pueden verificar simultáneamente varias credenciales digitales verificables de diferentes emisores, lo que permite implementar un proceso de procesamiento de datos ágil y económico. No es necesario contactar con varios emisores diferentes. Más bien, la cadena de bloques de la infraestructura SSI puede ser suficiente para la verificación.

El W3C utiliza identificadores descentralizados (“decentralized identifiers"/DID) (véase https://www.w3.org/TR/didcore/) y credenciales digitales verificables(“verifiable credentials"/VC)(véase https:// www.w3.org/TR/vc-data-model/). Estos estándares permiten identificar un sujeto DID, es decir, una entidad como un usuario o una organización, etc., sin depender de servicios centrales. La Decentralized Identity Foundation (DIF) (véase https://identity.foundation/) contiene una estandarización para DIDComm (https://github.com/decentralized-identity/DIDComm-messaging), una seguridad basada en la capa de comunicación descentralizada de DID.

Con credenciales verificables digitalmente, los atributos de usuario verificables se pueden intercambiar directamente entre un emisor y un titular o entre un titular y un verificador.

Una red de registro público que requiere autorización(“public permissioned ledger’)o una red de cadenas de bloques puede, por ejemplo, representar una red de identidad que promueva ventajosamente la privacidad de los usuarios. Dado que en el registro o en la cadena de bloques solo se almacena información pública de emisores y verificadores, en particular emisores y verificadores institucionales, pero no datos relacionados con el usuario, los problemas clásicos de DLT como el escalamiento, la eficiencia y el consumo de energía se pueden resolver de manera efectiva.

Una pila SSI, por ejemplo, se divide en cuatro capas. El modelo de capa SSI comprende servicios públicos(“public Utilities")o instalaciones de infraestructura en la primera capa, la más baja, y protocolos para conexiones criptográficamente seguras en la segunda capa, por ejemplo, protocolos DIDComm Peer-to-Peer(“DIDComm Peerto Peer Protoco!’),en la capa superior, protocolos de intercambio de datos de tercera capa('data exchange protocols")y en la cuarta capa superior, el ecosistema de aplicaciones ("application ecosystem").La base y la infraestructura están formadas por una cadena de bloques, es decir, un registro distribuido o un almacenamiento de datos distribuido ("distributedledger').La cadena de bloques es operada por nodos seleccionados y contiene los datos públicos de las entidades participantes. Las identidades de los participantes se realizan a través de identificadores descentralizados("decentralized identifiers"/DID).Un DID, similar a una URL, se puede resolver en un documento de identificación o documento DID ("DIDdocument'),que se almacena en la cadena de bloques. Datos como interfaces de servicio o claves públicas se almacenan en el documento DID. Los emisores también almacenan metadatos sobre las credenciales en la cadena de bloques, por ejemplo, esquemas o datos de revocación.

Las identidades representadas por DID pueden establecer una conexión criptográficamente segura en la capa superior. El protocolo estandarizado como “DIDComm” define actividades desde establecer una conexión hasta intercambiar mensajes. Los DID y el material de claves asociado se almacenan en carteras y son utilizados por los programas informáticos o agentes de software correspondientes.

La capa tres es donde tiene lugar el intercambio y la conexión reales entre las tres partes del ecosistema SSI. Los emisores o verificadores están en contacto directo con el titular. El emisor emite credenciales digitales verificables al titular. Estos pueden ser solicitados por el verificador y presentados por el titular. La confianza entre verificador y emisor se refleja indirectamente a través de la red.

En última instancia, la cuarta capa representa la aplicación de la tecnología SSI, por ejemplo, en procesos de negocios, cuando se trata con autoridades y otras aplicaciones que proporcionan pruebas de identidades y autenticaciones. La pila técnica de SSI va acompañada de un marco legal organizacional que rige las reglas de la red SSI y aclara la conexión legal y regulatoria con el mundo real.

SSI permite proporcionar una capa interoperable y reutilizable para procesos de identificación y autenticación. Por ejemplo, el funcionamiento de la infraestructura SSI puede garantizarse mediante un grupo fijo de operadores de red, así como mediante medidas organizativas y técnicas. Para servir como base sólida para los participantes involucrados, por ejemplo, emisores, titulares, verificadores, la infraestructura SSI cumple en particular las siguientes propiedades: garantiza que las transacciones en la cadena de bloques no puedan ser falsificadas y/o que se asignen claramente a su autor. lo que significa que se puede garantizar la autenticidad de los datos. Al verificar el estado actual de la cadena de bloques, se puede garantizar la integridad de los datos proporcionados por la cadena de bloques. Incluso en el caso de varios operadores de nodos defectuosos, se puede garantizar la fiabilidad de la red de cadenas de bloques y, por tanto, la disponibilidad, redundancia y solidez del almacenamiento de datos. Dado que los datos de prueba almacenados en la cadena de bloques, por ejemplo, de forma públicamente accesible, son datos de prueba no personales que deben ser accesibles públicamente y asignables a una entidad pública, la confidencialidad y el anonimato no desempeñan ningún papel a este respecto.

La infraestructura SSI utilizada comprende, por ejemplo, una cadena de bloques pública que requiere aprobación, es decir, autorización pública. Por un lado, esta tecnología de contabilidad combina propiedades de variantes de cadena de bloques públicas y sin permiso, como Bitcoin y Ethereum, con propiedades de variantes de cadena de bloques privadas y con permiso, como R3 Corda e Hyperledger Fabric. La red de cadenas de bloques comprende varios servidores de cadenas de bloques, que sirven, por ejemplo, como nodos de red o nodos de validación("validator nodes"),que son operados por actores especialmente calificados o designados("stewards")de acuerdo con una red de cadenas de bloques que requiere aprobación. Los nodos de la red generan confianza entre sí, por ejemplo, mediante un algoritmo de consenso. Por ejemplo, se puede llegar a un consenso utilizando el Protocolo Plenum, un algoritmo redundante de tolerancia a fallas bizantinas (RBFT), que representa una versión redundante del PBFT, que ha sido evaluado como seguro. Debido al algoritmo, se requiere un número N = 3F 1 del total de nodos en la red de cadenas de bloques para un número máximo F de nodos de red que actúan de manera maliciosa o incorrecta. Un tamaño razonable de una red de cadenas de bloques comprende, por ejemplo, 25 nodos de red y/o alrededor de 25 nodos de red, de modo que se garantice una buena fiabilidad y el correspondiente algoritmo de consenso pueda funcionar de la forma más eficiente posible. La eficiencia de RBFT y el alto rendimiento con un bajo gasto de recursos corresponden a las ventajas de una cadena de bloques autorizada.

Por ejemplo, el acceso de lectura a la red de cadenas de bloques o a la cadena de bloques proporcionada por la red de cadenas de bloques es de libre acceso y no requiere ninguna autenticación, de forma análoga a las propiedades típicas de una cadena de bloques pública. Sin embargo, el acceso por escrito, por ejemplo, requiere aprobación y, además de la firma del autor, también requiere el consentimiento de una persona autorizada(“endorser’).Por ejemplo, como transacción inicial, un autor crea su DID y deposita su clave criptográfica pública derivada. El autor firma todas las transacciones posteriores con su propia clave criptográfica privada, de modo que la autenticidad de los datos esté garantizada y pueda verificarse fácilmente. El autor envía las transacciones resultantes a varios nodos de la red de cadenas de bloques y tan pronto como recibe más de F 1 respuestas positivas, se logra la finalidad o coherencia. En una red de cadenas de bloques correspondiente, el consenso sobre los datos correspondientes se puede almacenar, por ejemplo, mediante una firma múltiple Boneh-Lynn-Shacham (BLS), que demuestra la coherencia inequívoca de los nodos de la red, de modo que solo un nodo debe ser consultado para una solicitud de lectura. Por ejemplo, las transacciones guardadas se almacenan como una lista ordenada con un árbol Merkle. El estado correcto de la cadena de bloques se puede comprobar mediante una prueba del estado actual y un registro de verificación del árbol Merkle. La autenticidad de las personas autorizadas puede garantizarse, por ejemplo, utilizando claves criptográficas públicas que se les asignan desde un archivo génesis de la red de cadenas de bloques.

Para hacer cumplir las reglas de la red de cadenas de bloques que requiere permiso, a la cadena de bloques se le asigna su propia configuración y un sistema integrado de derechos y reglas. Este sistema comprende, por ejemplo, lo siguiente: un administrador(“trustee")gestiona los derechos de otros miembros y puede establecer las reglas. Un actor(“steward’)opera un nodo de la red. Un endosante(“endorser’)confirma el acceso de escritura de las transacciones de datos habituales. Un monitor de red(“network monitor’)monitorea y analiza los metadatos para el funcionamiento adecuado de la red.

Por ejemplo, el DID de un emisor se almacena en la cadena de bloques o en la red de cadenas de bloques junto con la clave criptográfica pública del emisor. Por lo tanto, su identidad puede verificarse dentro de la red de cadenas de bloques utilizando estas claves criptográficas públicas. Se pueden utilizar medidas técnicas para garantizar que los datos emitidos o una credencial digital verificable no puedan ser falsificados, es decir, su integridad y autenticidad. Un verificador comprueba la autenticidad validando la firma del emisor. Para ello, se puede utilizar, por ejemplo, un esquema de firma que admita Zero Knowledge Proof (ZKP), como los métodos de firma Camenisch-Lysyanskaya o BBS+. Como parte de dicha verificación de firma, el verificador solo descubre que el titular demuestra conocimiento de una firma válida de los atributos de usuario revelados. Esto puede permitir, por ejemplo, una divulgación selectiva y/o declaraciones lógicas.

Las formas de realización pueden implementar además una forma de recuperar las credenciales digitales verificables emitidas. Esto puede resultar necesario, por ejemplo, debido a datos emitidos incorrectamente o desactualizados, debido al mal uso de la credencial digital verificable o a la pérdida de una clave criptográfica privada asociada. Por ejemplo, dos puntos destacan como mecanismos que promueven la privacidad: por un lado, no es necesaria una conexión directa con el emisor para comprobar la validez de una credencial digital verificable. En su lugar, se utilizan datos de verificación de cadena de bloques de acceso público y de alta disponibilidad. Por otro lado, en este contexto también se utilizan ZKP, de modo que en esta prueba también se puede evitar una correlación entre diferentes procesos realizados por la misma persona. Esto se puede realizar, por ejemplo, mediante un algoritmo de verificación basado en un acumulador criptográfico.

Por ejemplo, la estructuración mediante JSON-LD se utiliza para las credenciales digitales verificables.

Por "token de ID" se entiende aquí un dispositivo electrónico portátil, por ejemplo, una tarjeta con chip o un documento en el que se almacenan los atributos de un usuario. Por "documento" se entiende, en particular, un documento de identificación, de valor o de seguridad, en particular un documento soberano, en particular un documento en papel y/o plástico, como un documento de identificación electrónico, en particular un pasaporte, documento de identidad, visado, permiso de conducir, documento de matriculación de vehículos, tarjeta sanitaria o documento de identidad de empresa u otro documento de identidad, tarjeta con chip, medio de pago, en particular billetes, tarjetas bancarias o tarjetas de crédito, cartas de porte u otra prueba de autorización. En particular, el token de ID puede ser un documento de viaje legible por máquina, como el estandarizado por la Autoridad de Aviación Internacional (OACI) y/o la Oficina Federal para la Seguridad de la Información (BSI).

Se entiende por elemento de seguridad un elemento asegurado de un terminal móvil que proporciona medios criptográficos. Estos medios criptográficos están protegidos contra la manipulación y solo son accesibles para servicios y aplicaciones autorizados, por ejemplo, mediante claves criptográficas. En particular, los medios criptográficos solo pueden introducirse, complementarse, modificarse y/o eliminarse en el elemento de seguridad, por ejemplo, mediante servicios y aplicaciones autorizados. Por lo tanto, un elemento de seguridad ofrece una plataforma a prueba de manipulaciones, implementada, por ejemplo, en forma de un microcontrolador seguro de un solo chip, en el que se almacenan applets y/o datos y/o criptográficos según reglas predefinidas y requisitos de seguridad de personas confiables identificadas de manera confiable. Se pueden poner a disposición instancias y, por tanto, programas de aplicación autorizados, como, por ejemplo, un cartera de aplicaciones, y/o sistemas operativos. Un elemento de seguridad puede estar empotrado o integrado, por ejemplo, desmontable de forma no destructiva o unido firmemente, es decir, no desmontable de forma no destructiva. Un elemento de seguridad se puede implementar, por ejemplo, en forma de un Elemento Seguro (SE). El elemento de seguridad puede incluir, por ejemplo, una SIM, UICC, SmartMicroSD, Smartcard, eSE, eSIM o eUICC. Por ejemplo, las claves criptográficas se almacenan en un elemento de seguridad, es decir, el elemento de seguridad comprende una bóveda de datos para claves criptográficas o un "almacén de claves". Un almacén de claves o un elemento de seguridad de este tipo también se puede implementar como parte del procesador principal, por ejemplo, en un TEE("Trusted Execution Environment').Por ejemplo, el elemento de seguridad se puede implementar mediante un TEE. Los elementos de seguridad se implementan, por ejemplo, comohardwarey/ofirmware.Según formas de realización también se pueden implementar como software elementos de seguridad o almacenes de claves. Por ejemplo, dos elementos de seguridad son independientes entre sí si no existe una instancia común que tenga autorización de acceso para ambos elementos de seguridad.

Por "programa" o "instrucciones de programa" se entiende aquí, sin limitación, cualquier tipo de programa informático que incluya instrucciones legibles por máquina para controlar una funcionalidad del ordenador.

Aquí y en lo sucesivo, se entiende por "procesador" un circuito lógico que se utiliza para ejecutar instrucciones de programa. El circuito lógico puede estar implementado en uno o varios componentes discretos, en particular en un chip. Por "procesador" se entiende especialmente un microprocesador o un sistema de microprocesador compuesto por varios núcleos de procesador y/o varios microprocesadores.

"Memoria" aquí se refiere a memorias electrónicas o medios de almacenamiento digitales tanto volátiles como no volátiles.

Por "memoria no volátil" se entiende aquí una memoria electrónica para el almacenamiento permanente de datos, en particular claves, atributos o identificadores criptográficos estáticos. La memoria no volátil se puede configurar como memoria no modificable, también conocida como memoria de solo lectura (ROM), o memoria modificable, también conocida como memoria no volátil (NVM). En particular, ésta puede ser una EEPROM, por ejemplo, una EEPROM flash, abreviada como flash. Una memoria no volátil se caracteriza por el hecho de que los datos almacenados en ella se conservan incluso después de que se corta el suministro eléctrico.

Por "interfaz" o "interfaz de comunicación" se entiende aquí una interfaz a través de la cual se pueden recibir y enviar datos, pudiendo configurarse la interfaz de comunicación como basada en contacto o sin contacto. Una interfaz de comunicación puede, por ejemplo, permitir la comunicación a través de una red. Dependiendo de la configuración, una interfaz de comunicación puede proporcionar, por ejemplo, comunicación inalámbrica según un estándar celular, Bluetooth, RFID, WiFi y/o NFC. Dependiendo de la configuración, una interfaz de comunicación puede proporcionar, por ejemplo, una comunicación por cable. La interfaz de comunicación puede ser una interfaz interna o una interfaz externa.

Los canales de comunicación cifrados son, por ejemplo, conexiones cifradas de extremo a extremo. Por “conexión cifrada de extremo a extremo” o “canal de comunicación cifrado de extremo a extremo” se entiende aquí una conexión entre un remitente y un receptor con cifrado de extremo a extremo, en la que los datos a transmitir es cifrado por el remitente y solo descifrado nuevamente por el receptor. De este modo, el cifrado de los datos transmitidos se realiza en todas las estaciones de transmisión, de modo que las estaciones intermedias no pueden conocer el contenido de los datos transmitidos debido al cifrado. La conexión está criptográficamente protegida mediante cifrado para evitar el espionaje y/o manipulación de la transmisión, para lo cual se puede utilizar el llamado proceso de mensajería segura. El cifrado de extremo a extremo se basa, por ejemplo, en dos claves criptográficas simétricas, siendo una primera de las claves simétricas para cifrar mensajes y una segunda de claves simétricas para autenticar al remitente del mensaje, por ejemplo, utilizando el Código de autenticación de mensajes (MAC) sirve algoritmos. Por ejemplo, para un canal de comunicación cifrado, durante la configuración se negocian claves efímeras para el cifrado, que pierden su validez cuando se finaliza el canal de comunicación. El uso de diferentes claves efímeras para diferentes canales de comunicación hace posible operar una pluralidad de canales de comunicación en paralelo entre sí.

Se puede establecer un canal de comunicación cifrado, por ejemplo, utilizando el protocoloTransport Layer Security(TLS), por ejemplo, como parte del protocolo Hypertext Transfer Protocol Secure (HTTPS).

Los pares de claves asimétricas se utilizan para una variedad de criptosistemas y desempeñan un papel importante en la transmisión segura de datos electrónicos. Un par de claves asimétricas consta de una clave criptográfica pública, que se utiliza para cifrar y/o descifrar datos y que puede transmitirse a terceros, por ejemplo, a un remitente o receptor de datos, y una clave criptográfica privada, que se utiliza para cifrar y descifrar datos/o descifrar, pero también se utiliza para firmar datos y, por lo general, debe mantenerse en secreto. La clave pública permite a cualquier persona cifrar datos para el titular de la clave criptográfica privada o verificar firmas digitales creadas con la clave criptográfica privada. Una clave privada permite a su titular descifrar datos cifrados con la clave criptográfica pública o crear firmas digitales de datos.

Una firma digital de datos comprende, por ejemplo, formar un valor de verificación de los datos, como un valor hash, que se cifra con una clave criptográfica privada de un par de claves asimétricas utilizadas como clave de firma. En el caso de una firma, solo el firmante conoce la clave criptográfica privada utilizada para crear la firma, es decir, la clave de firma, del par de claves asimétricas utilizadas para la firma. El destinatario de la firma solo dispone de la clave criptográfica pública, es decir, la clave de verificación de la firma, del par de claves asimétricas utilizadas para la firma. Por lo tanto, el destinatario de la firma puede comprobar la firma, pero no puede calcularla por sí mismo. Para una verificación de firma, el destinatario de la firma calcula, por ejemplo, el valor de verificación de los datos firmados y lo compara con el resultado de descifrar la firma utilizando la clave de verificación de firma. Si el valor hash calculado coincide con el resultado del descifrado, la firma es correcta. Si también se confirma la autenticidad de la clave de verificación de firma, por ejemplo, mediante un certificado, en particular un certificado PKI, la firma es válida.

Por "certificado" se entiende aquí un certificado digital, también denominado certificado de clave pública (certificado PKI). Un certificado son datos estructurados que se utilizan para asociar una clave criptográfica pública de un criptosistema asimétrico con una identidad, como una persona, institución o dispositivo. Por seguridad criptográfica y para demostrar la autenticidad de los datos del certificado, están firmados por un emisor del certificado. Se implementó la denominada Infraestructura de Clave Pública (PKI). Por ejemplo, el certificado puede ajustarse al estándar X.509 u otro estándar. Por ejemplo, el certificado es un Certificado verificable con tarjeta (CVC). Un certificado de autorización comprende datos estructurados que definen además los derechos de identidad.

La PKI proporciona un sistema para emitir, distribuir y verificar certificados digitales. En un criptosistema asimétrico, un certificado digital puede confirmar la autenticidad de una clave criptográfica pública y su alcance y alcance permisibles. El certificado digital está a su vez protegido por una firma digital cuya autenticidad puede comprobarse utilizando la clave criptográfica pública del emisor del certificado. Se utiliza un certificado digital para comprobar la autenticidad de la clave del emisor. De esta forma se puede construir una cadena de certificados digitales, cada uno de los cuales confirma la autenticidad de la clave criptográfica pública que puede utilizarse para comprobar el certificado anterior. Una cadena de certificados de este tipo forma la denominada ruta de validación o ruta de certificación. Los participantes de la PKI deben poder confiar en la autenticidad del último certificado, el llamado certificado raíz, y de la clave certificada por él, por ejemplo, sin necesidad de ningún otro certificado. El certificado raíz lo gestiona una autoridad de certificación raíz, en cuya autenticidad se basa la autenticidad de todos los certificados PKI.

Los certificados digitales son confirmados, por ejemplo, por una autoridad independiente y creíble (proveedor de servicios de certificación/ZDA o proveedor de servicios de confianza/VDA), es decir, el organismo de certificación que emite el certificado. Los certificados pueden ponerse a disposición de una amplia gama de personas para permitirles comprobar la autenticidad y validez de las firmas electrónicas. Un certificado puede asociarse con una firma electrónica y proporcionar una clave de verificación de firma en forma de clave criptográfica pública si la clave privada asociada con la clave de verificación de firma se utilizó como clave de firma. Al poner a disposición del público en general un certificado asociado con una clave criptográfica pública, un ZDA/VDA permite a los usuarios de criptosistemas asimétricos asignar la clave criptográfica pública a una identidad, por ejemplo, una persona, una organización o un sistema informático.

Un ordenador o un sistema informático puede ser, por ejemplo, un ordenador fijo, como, por ejemplo, un ordenador personal (PC), un terminal de servicio o un servidor, o un ordenador portátil móvil, como, por ejemplo, un ordenador portátil, una tableta, un teléfono inteligente u otro Dispositivo inteligente. El ordenador puede incluir una interfaz para la conexión a la red, cuya red puede ser una red pública o privada, en particular Internet. Según la configuración, esta conexión también se puede establecer a través de una red móvil.

Por terminal móvil se entiende, por ejemplo, un dispositivo de comunicación móvil y portátil, como, por ejemplo, un teléfono inteligente, una tableta o un reloj inteligente.

Según formas de realización, el esquema de datos también sirve como plantilla para crear la credencial digital verificable.

Según formas de realización, habilitar el acceso de lectura del sistema informático proveedor de ID comprende: • Autenticar al usuario con el token de ID utilizando el terminal móvil,

• Autenticar el sistema informático proveedor de ID frente al token de ID a través del terminal móvil utilizando un certificado de lectura basado en PKI del sistema informático proveedor de ID para leer los atributos del usuario del token de ID,

• Tras la autenticación exitosa del usuario y el sistema informático proveedor de ID con el token de ID, se libera el acceso de lectura del sistema informático proveedor de ID.

Según formas de realización, el terminal móvil establece un primer canal de comunicación cifrado a través de la red con el sistema informático emisor, a través del cual se envía la solicitud de emisión.

Según formas de realización, el primer canal de comunicación cifrado es un canal TLS.

Según formas de realización, el primer canal de comunicación cifrado es un canal TLS, es decir, un canal de comunicación cifrado utilizando el protocolo de cifrado TLS.

Según formas de realización, el sistema informático emisor se autentica en el terminal móvil durante la configuración del primer canal de comunicación cifrado.

Según formas de realización, el terminal móvil comprende además un programa cliente a través del cual el sistema informático proveedor de ID lee el acceso al token de ID, en el que el sistema informático proveedor de ID lee el acceso al token de ID a través de un segundo canal de comunicación cifrado.

Según formas de realización, el primer canal de comunicación cifrado lo configura el terminal móvil utilizando un navegador instalado en el terminal móvil, comprendiendo el segundo canal de comunicación cifrado:

• llamar a un sitio web del emisor utilizando el navegador, proporcionando el sitio web una URL para recuperar parámetros para configurar el segundo canal de comunicación cifrado para leer los atributos del usuario,

• llamar a la URL usando el navegador,

• proporcionar los parámetros incluidos en la URL llamada al programa cliente,

• establecer el segundo canal de comunicación cifrado a través del programa cliente utilizando los parámetros proporcionados por la URL.

Según formas de realización, el usuario accede al sitio web del emisor utilizando el navegador del terminal móvil. Según formas de realización, el usuario accede al sitio web del emisor directamente desde el navegador. Según formas de realización, la cartera de identificación comprende un elemento funcional, cuya activación inicia el navegador para acceder al sitio web del emisor.

Según formas de realización, el primer canal de comunicación cifrado lo configura el terminal móvil a través de la cartera de identificación, comprendiendo la configuración del segundo canal de comunicación cifrado:

• en respuesta a la solicitud de emisión, recibir la URL para recuperar los parámetros para establecer el segundo canal de comunicación cifrado a través de la cartera de identificación,

• llamar a la URL a través de la cartera de identificación,

Según formas de realización, el método comprende además configurar un tercer canal de comunicación cifrado entre la cartera de identificación y el sistema informático emisor, a través del cual la cartera de identificación recibe la credencial digital verificable, comprendiendo la configuración del tercer canal de comunicación cifrada la autenticación mutua entre la cartera de identificación y el sistema informático emisor.

Según formas de realización, el navegador recibe una solicitud para configurar el tercer canal de comunicación cifrado, comprendiendo la solicitud uno o más parámetros del sistema informático emisor para configurar el tercer canal de comunicación cifrado y el navegador que proporciona la solicitud de la cartera de identificación para configurar el tercer canal de comunicación cifrado.

Según formas de realización, el navegador recibe la solicitud para configurar el tercer canal de comunicación cifrado tras la lectura exitosa de los atributos del usuario.

Según formas de realización, el navegador recibe la solicitud para configurar el tercer canal de comunicación cifrado en respuesta a la llamada al sitio web del servicio emisor, siendo el establecimiento exitoso del tercer canal de comunicación cifrado un requisito previo para configurar el segundo canal de comunicación cifrado para leer los atributos del usuario.

Según formas de realización, la URL para configurar el segundo canal de comunicación cifrado solo se proporciona al navegador del terminal móvil, por ejemplo, después de que el tercer canal de comunicación cifrado se haya configurado con éxito.

Según formas de realización, la cartera de identificación comprende el programa cliente, enviándose la solicitud de emisión mediante el programa cliente, estableciendo el primer canal de comunicación cifrado entre la cartera de identificación y el sistema informático emisor.

Según formas de realización, la solicitud de emisión se envía al sistema informático emisor mediante una llamada API.

Según formas de realización, en respuesta a la solicitud de emisión, la cartera de identificación recibe la solicitud para establecer un tercer canal de comunicación cifrado entre la cartera de identificación y el sistema informático emisor y establece el tercer canal de comunicación cifrado utilizando los parámetros proporcionados por la solicitud. siendo un establecimiento exitoso del tercer canal de comunicación cifrado un requisito previo para el establecimiento del segundo canal de comunicación cifrado, que se establece como un subcanal cifrado en el tercer canal de comunicación.

Según formas de realización, la URL para configurar el segundo canal de comunicación cifrado de la cartera de identificación del terminal móvil solo se proporciona, por ejemplo, después de que el tercer canal de comunicación cifrado se haya configurado con éxito.

Según formas de realización, el tercer canal de comunicación cifrado es un canal DIDComm.

Por ejemplo, el tercer canal de comunicación cifrado es un canal DIDComm, es decir, un canal de comunicación cifrado utilizando el protocolo de cifrado DIDComm.

Según formas de realización, el sistema informático emisor comprende el sistema informático proveedor de ID.

Según formas de realización, el sistema informático emisor y el sistema informático proveedor de ID son el mismo sistema informático. Por ejemplo, un programa de proveedor de ID se instala en el sistema informático emisor y se configura para realizar las funciones de un proveedor de ID descrito en el presente documento. Si el sistema informático emisor comprende el sistema informático proveedor de ID, el reenvío de los atributos de usuario leídos desde el sistema informático proveedor de ID al sistema informático emisor es un reenvío interno de los atributos de usuario leídos dentro del sistema informático emisor. Por ejemplo, los atributos de usuario leídos se envían desde un programa proveedor de ID instalado en el sistema informático emisor a un programa del emisor instalado en el sistema informático emisor. Según formas de realización, el sistema informático proveedor de ID es un sistema informático que es independiente del sistema informático emisor.

Según formas de realización, el sistema informático proveedor de ID reenvía los atributos de usuario leídos al sistema informático emisor a través de un cuarto canal de comunicación cifrado.

Según formas de realización, el cuarto canal de comunicación cifrado es un canal TLS.

Por ejemplo, el cuarto canal de comunicación cifrado es un canal TLS, es decir, un canal de comunicación cifrado utilizando el protocolo de cifrado TLS.

Las formas de realización comprenden además un terminal móvil para leer uno o más atributos de usuario de un token de ID y proporcionar una credencial digital verificable con los atributos de usuario leídos en una cartera de identificación digital del terminal móvil, realizándose la lectura a través del terminal móvil usando un sistema informático proveedor de identificación de un servicio proveedor de identificación, siendo la credencial digital verificable proporcionada una credencial digital verificable emitida utilizando un sistema informático emisor de un servicio emisor de una infraestructura SSI,

en el que la infraestructura SSI comprende una cadena de bloques en la que se almacenan un esquema de datos para la credencial digital verificable y una clave criptográfica pública asignada al servicio emisor, sirviendo el esquema de datos como plantilla para verificar la credencial digital verificable, utilizándose la clave criptográfica pública del el servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave criptográfica privada del servicio emisor asignada a la clave de verificación de firma como clave de firma,

comprendiendo el terminal móvil un procesador, una memoria con instrucciones de programa, una interfaz de comunicación para la comunicación con el token de ID y una interfaz de comunicación para la comunicación a través de una red,

permitiendo la ejecución de las instrucciones de programa por parte del procesador del terminal móvil que el procesador controle el terminal móvil para:

• enviar una solicitud de emisión para emitir la credencial digital verificable desde el terminal móvil a través de la red al sistema informático emisor para iniciar una lectura de los atributos del usuario por parte del sistema informático proveedor de ID desde el token de ID,

• permitir el acceso de lectura del sistema informático proveedor de ID a los atributos de usuario almacenados en un área de memoria protegida de una memoria del token de ID a través del terminal móvil y la red para reenviar los atributos de usuario leídos al sistema informático emisor,

• recibir la credencial digital verificable emitida por el servicio emisor a través de la cartera de identificación digital del terminal móvil desde el sistema informático emisor a través de la red, construyéndose la credencial digital verificable de acuerdo con el esquema de datos proporcionado en la cadena de bloques, que comprende los atributos de usuario leídos y utilizando la clave de firma del servicio emisor,

• almacenar la credencial digital verificable recibida en la cartera de identificación del terminal móvil.

Las formas de realización comprenden además un sistema informático emisor de un servicio emisor de una infraestructura SSI para leer uno o más atributos de usuario de un token de ID y proporcionar una credencial digital verificable con los atributos de usuario leídos en una cartera de identificación digital de un terminal móvil, realizándose la lectura a través del terminal móvil utilizando un sistema informático de proveedor de ID de un servicio proveedor de ID,

comprendiendo la infraestructura SSI una cadena de bloques en la que se almacenan un esquema de datos para la credencial digital verificable y una clave criptográfica pública asignada al servicio emisor, sirviendo el esquema de datos como plantilla para verificar la credencial digital verificable, utilizándose la clave criptográfica pública del el servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave criptográfica privada del servicio emisor asignada a la clave de verificación de firma como clave de firma,

comprendiendo el sistema informático emisor un procesador, una memoria con instrucciones de programa y una interfaz de comunicación para comunicación a través de una red,

permitiendo la ejecución de las instrucciones de programa por parte del procesador del sistema informático emisor que el procesador controle el sistema informático emisor para:

• recibir una solicitud de emisión de la credencial digital verificable desde el terminal móvil a través de la red,

• iniciar una lectura de los atributos de usuario por parte del sistema informático proveedor de ID desde un área de memoria protegida de una memoria del token de ID en respuesta a la solicitud de emisión,

• recibir atributos de usuario leídos a través del terminal móvil y la red desde el sistema informático proveedor de ID,

• emitir la credencial digital verificable, que comprende los atributos de usuario leídos, se construye de acuerdo con el esquema de datos proporcionado en la cadena de bloques y se firma utilizando la clave de firma del servicio emisor.

• enviar la credencial digital verificable emitida a través de la red a la cartera de identificación del terminal móvil.

Según formas de realización, el sistema informático emisor comprende el sistema informático proveedor de ID para leer los atributos de usuario del token de ID.

Las formas de realización comprenden además un sistema para leer uno o más atributos de usuario de un token de ID y proporcionar una credencial digital verificable con los atributos de usuario leídos en una cartera de identificación digital de un terminal móvil de acuerdo con una de las formas de realización antes mencionadas de un terminal móvil que utiliza un sistema informático emisor de un servicio emisor de una infraestructura SSI, siendo el sistema informático emisor un sistema informático emisor según una de las formas de realización antes mencionadas de un sistema informático emisor y realizándose la lectura por parte del sistema informático emisor a través del terminal móvil mediante un sistema informático proveedor de ID de un servicio proveedor de identificación.

Según formas de realización, el sistema comprende además el sistema informático proveedor de ID.

Según formas de realización, el sistema informático emisor comprende el sistema informático proveedor de ID para leer los atributos de usuario del token de ID. Según formas de realización, el sistema informático proveedor de ID es un sistema informático que es independiente del sistema informático emisor.

Según formas de realización, el sistema comprende además la cadena de bloques.

A continuación se explican con más detalle formas de realización de la invención con referencia a los dibujos. Se muestra en la:

Figura 1 un diagrama de bloques esquemático de un sistema ejemplar para emitir una credencial digital verificable,

Figura 2 un diagrama de flujo esquemático de un método ejemplar para emitir una credencial digital verificable,

Figura 3 un diagrama de flujo esquemático de otro método ejemplar para emitir una credencial digital verificable,

Figura 4 un diagrama de bloques esquemático de otro sistema ejemplar para emitir una credencial digital verificable,

Figura 5 un diagrama de flujo esquemático de otro método ejemplar para emitir una credencial digital verificable,

Figura 6 un diagrama de bloques esquemático de otro sistema ejemplar para emitir una credencial digital verificable,

Figura 7 un diagrama de flujo esquemático de otro método ejemplar para emitir una credencial digital verificable,

Figura 8 un diagrama de flujo esquemático de un método ejemplar para usar una credencial digital verificable, y

Figura 9 un diagrama de bloques esquemático de un sistema ejemplar para emitir una credencial digital verificable.

Los elementos de las siguientes formas de realización que se corresponden entre sí se identifican con los mismos signos de referencia.

La Figura 1 muestra un sistema 101 ejemplar, que está configurado para proporcionar credenciales digitales verificables con atributos de usuario que provienen de un token 200 de ID. El sistema comprende un terminal móvil en el que está instalada una cartera 102 de identificación con un área 104 de memoria protegida para almacenar de forma segura credenciales digitales verificables. Además, en el terminal móvil están instalados un navegador 106 y un programa 108 cliente para leer el token 200 de ID. Además, el sistema 300 informático comprende un programa 302 emisor para emitir credenciales digitales verificables y un programa 304 de utilidad(eService)para inicializar una lectura del token 200 de ID. Además, el programa de servicio emisor proporciona un servicio 306 de revocación para revocar credenciales digitales verificables emitidas. Además, el sistema 100 dispone de una cadena 400 de bloques de una infraestructura SSI, en la que se almacenan credenciales digitales verificables y claves criptográficas públicas, que se asignan a emisores de credenciales verificables. Finalmente, el sistema 100 comprende, además del token 200 de ID, desde el cual se leen los atributos del usuario para crear la credencial digital verificable, un sistema 500 informático proveedor de ID de un servicio proveedor de ID. El servidor de ID tiene credenciales que le permiten leer atributos de usuario del token 200 de ID.

El sistema 300 informático de servicio emisor utiliza el sistema 500 informático proveedor de ID para leer atributos de usuario del token 200 de ID. La lectura de atributos de usuario del token de ID se lleva a cabo a través de la mediación del programa 108 cliente de ID del terminal 100 móvil. El sistema 500 informático proveedor de ID pone los atributos de usuario leídos a disposición del sistema 300 informático de servicio emisor. Por ejemplo, los atributos de usuario leídos proporcionados por el sistema 500 informático proveedor de ID están firmados con una clave de firma del servidor, demostrando así su autenticidad. El sistema 300 informático emisor utiliza los atributos de usuario leídos para crear una credencial digital verificable, que el sistema informático emisor firma con una clave de firma y envía a la cartera 102 de identificación del terminal móvil a través de un canal de comunicación cifrado. El canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor del sistema 300 informático emisor requiere autenticación mutua entre la cartera 102 de identificación y el programa 302 emisor.

El servicio de emisión de credenciales digitales verificables que proporciona el sistema 300 informático es un servicio de emisión de una infraestructura SSI. La infraestructura SSI utilizada por el servicio emisor comprende, por ejemplo, la cadena 400 de bloques. La cadena 400 de bloques, por ejemplo, proporciona esquemas de datos para emitir credenciales digitales verificables. Estos esquemas de datos describen la composición estructural de las correspondientes credenciales digitales verificables. Además, en la cadena 400 de bloques se almacenan claves criptográficas públicas de los emisores de la infraestructura SSI. Esta cadena 400 de bloques, por ejemplo, es una cadena de bloques pública que requiere permiso, en la que el acceso de escritura está restringido, mientras que el acceso de lectura es posible para todos. La cadena 400 de bloques permite así verificar una credencial digital verificable. Para ello existe un acceso de lectura a la cadena 400 de bloques y se leen, por ejemplo, el esquema de datos almacenado para la credencial correspondiente y la clave criptográfica pública del emisor de la credencial a verificar. Usando el esquema de datos apropiado, se puede verificar si la credencial digital verificable actual tiene la estructura almacenada y comprende todos los tipos de datos necesarios para una verificación exitosa. Por ejemplo, los esquemas de datos comprenden información sobre los tipos de datos necesarios para la verificación, por ejemplo, sobre ciertos tipos de atributos de usuario, que se almacenan en el token 200 de ID. Además, la clave criptográfica pública almacenada por el emisor se puede utilizar para comprobar la firma de la credencial digital verificable.

Además, en la cadena 400 de bloques se pueden almacenar, por ejemplo, avisos de revocación que proporcionan información sobre una revocación de una credencial digital verificable emitida. En el curso de la verificación de una credencial digital verificable existente, la cadena 400 de bloques se puede utilizar para verificar si una entrada de revocación está almacenada en la cadena de bloques para la credencial correspondiente. Si se almacena una entrada de revocación en la cadena de bloques, es decir, se revoca la credencial correspondiente, el resultado de la verificación de la credencial correspondiente será negativo. Finalmente, se pueden almacenar parámetros en la cadena 400 de bloques para autenticar a los participantes en la comunicación. Por ejemplo, basándose en la información de autenticación correspondiente, la cartera 102 de identificación y el programa 302 emisor pueden iniciarse en el curso del establecimiento del canal de comunicación cifrado.

Una vez que la credencial verificable digitalmente se ha emitido y almacenado de forma segura en la cartera 102 de identificación, el usuario 10 puede usar la credencial verificable digitalmente correspondiente para su identificación. El usuario 10 ya no necesita el token 200 de ID. Para ello basta más bien con el terminal 100 móvil, por ejemplo, un teléfono inteligente. Con la cartera de identificación instalada en el terminal 100 móvil y las credenciales digitales verificables almacenadas en la cartera de identificación, el usuario 10 puede identificarse ante cualquier otra entidad. Esto funciona en particular de forma digital porque el terminal 100 móvil, si es necesario, selecciona una credencial digital verificable adecuada de la cartera 102 de identificación y la envía a la entidad correspondiente. La entidad receptora, es decir, un verificador, puede verificar la credencial digital verificable recibida utilizando la cadena 400 de bloques. Para ello, el verificador comprueba, por ejemplo, de la manera descrita anteriormente, utilizando la información contenida en la cadena 400 de bloques, como el esquema de datos, la clave criptográfica pública y/o notas, si la credencial digital verificable presentada es válida. Si la verificación tiene éxito, la credencial digital verificable se reconoce como auténtica y el usuario 10 se considera autenticado en base a los atributos de usuario proporcionados por las credenciales digitales verificables, que provienen del token 200 de ID.

La Figura 2 muestra un diagrama de flujo ejemplar de un método para leer atributos de usuario del token 200 de ID usando el sistema 500 informático proveedor de ID de un servicio proveedor de ID y proporcionando una credencial digital verificable con los atributos de usuario leídos por el sistema 300 informático emisor de un servicio emisor de una infraestructura SSI. El sistema 101 para llevar a cabo el método es el sistema 101 de la Figura 1. Inicialmente, el sistema 300 informático emisor del servicio emisor envía a la cadena 400 de bloques datos de identidad que identifican el servicio emisor. Los datos de identidad correspondientes comprenden, por ejemplo, una clave criptográfica pública del servicio emisor. Además se almacenan, por ejemplo, esquemas de datos de credenciales digitales verificables, que son emitidos por el servicio emisor. Los esquemas de datos correspondientes se almacenan, por ejemplo, junto con definiciones de credenciales, que definen los tipos de credenciales que emite el servicio emisor. Finalmente, la información de revocación, por ejemplo, también se almacena en la cadena 400 de bloques, que define cómo se revocan las credenciales emitidas por el servicio emisor.

En el paso 1, se inicia el proceso para emitir una credencial digital verificable para el usuario 10 usando el terminal 100 móvil. Para ello, el usuario 10 accede a un sitio web del servicio emisor, por ejemplo, utilizando el navegador 106 del terminal 100 móvil. La llamada puede, por ejemplo, exigir que el usuario 10 acepte las condiciones de protección de datos y de uso del servicio emisor. Alternativamente, este proceso también se puede iniciar utilizando un enlace proporcionado por la cartera de identificación. Si el usuario hace clic en el enlace correspondiente, se abre el sitio web del servicio emisor en el navegador 106 del terminal 100 móvil.

En el paso 2, el usuario 10 inicia el proceso del proveedor de ID, es decir, la lectura de atributos de usuario del token 200 de ID por el sistema 500 informático proveedor de ID a través del terminal 100 móvil. El usuario inicia el proceso del proveedor de ID hacia el servicio emisor, es decir, el sistema informático emisor, que responde proporcionando una URL. Los parámetros se almacenan bajo la URL correspondiente para establecer un canal de comunicación cifrado entre el programa 108 cliente del terminal 100 móvil y el sistema 500 informático proveedor de ID. El navegador web llama a la URL correspondiente y facilita los parámetros proporcionados a continuación al programa 108 cliente para establecer el canal de comunicación cifrado. El programa 108 cliente utiliza los parámetros proporcionados bajo la URL para iniciar el canal de comunicación cifrado con el sistema 500 informático proveedor de ID. En el paso 2a, el navegador 106 evalúa la respuesta del sistema 500 informático proveedor de ID y llama al programa 108 cliente.

En el paso 3, el programa 108 cliente proporciona información en un dispositivo de visualización del terminal 100 móvil, por ejemplo, en una pantalla, a la persona que lee o está autorizada para leer, es decir, el servicio proveedor de ID, los atributos de usuario solicitados por el servicio proveedor de ID y/o el uso previsto de los atributos de usuario que se van a leer. El usuario 10 puede comprobar la información mostrada y, si la acepta, introducir un PIN en el terminal 100 móvil a través de un dispositivo de entrada, por ejemplo, una pantalla configurada como pantalla táctil. El PIN correspondiente se envía al programa 108 cliente al token 200 de ID para su verificación. Si el PIN introducido es correcto, el programa 108 cliente establece una conexión entre el token 200 de ID y el sistema 500 informático proveedor de ID en forma de un canal de comunicación cifrado de extremo a extremo. El token de ID y el sistema informático proveedor de identificación pueden autenticarse entre sí a través de este canal de comunicación cifrado. Si la autenticación mutua tiene éxito y el sistema informático proveedor de ID puede demostrar la autorización de acceso para leer atributos de usuario del token 200 de ID, el sistema 500 informático proveedor de ID recibe acceso de lectura al token 200 de ID. La prueba de autorización correspondiente puede ser, por ejemplo, un certificado de lectura del servicio proveedor de ID.

En el paso 4, los atributos de usuario solicitados se transmiten desde el token 200 de ID al sistema 500 informático proveedor de ID a través del canal de comunicación cifrado entre el token 200 de ID y el sistema 500 informático proveedor de ID.

En el paso 5, el sistema 500 informático proveedor de ID responde al programa 108 cliente con una URL de redireccionamiento después de que los atributos del usuario se hayan leído con éxito. Esta URL de redireccionamiento comprende una sesión del proveedor de ID correspondiente al identificador, durante la cual se leyeron los atributos del usuario. El programa 108 cliente pasa la URL de redireccionamiento al navegador. En el paso 5a, el navegador 106 llama a la URL de redireccionamiento y, por lo tanto, proporciona al sistema 300 informático emisor información de que el proceso de lectura con la sesión del proveedor de ID especificada fue exitosa y al sistema 500 informático proveedor de ID los atributos de usuario que se van a leer del token 200 de ID presentes.

En el paso 6, el sistema 300 informático emisor solicita la lectura de los atributos del usuario desde el sistema 500 informático proveedor de ID cuando se invoca la URL de redireccionamiento. Para este propósito, por ejemplo, se establece un canal de comunicación cifrado, como un canal TLS, entre el sistema 300 informático emisor y el sistema 500 informático proveedor de ID. El sistema 300 informático emisor solicita la lectura de atributos de usuario desde el sistema 500 informático proveedor de ID, por ejemplo, utilizando el programa 304 de utilidad.

En el paso 7, en respuesta a la solicitud del sistema 300 informático emisor, el sistema 500 informático proveedor de ID envía los atributos de usuario leídos al sistema 300 informático emisor a través del canal de comunicación cifrado entre el sistema 500 informático proveedor de ID y el sistema 300 informático emisor. Los atributos de usuario leídos se firman, por ejemplo, a través del sistema 500 informático proveedor de ID con una clave de firma del sistema 500 informático proveedor de ID. La autenticidad de los atributos de usuario leídos es confirmada por el sistema 500 informático proveedor de ID mediante la firma correspondiente.

En el paso 8, el sistema 300 informático emisor o el programa 302 emisor, que está instalado en el sistema 300 informático emisor, genera una contraseña de bloqueo para revocar la credencial digital verificable que se va a emitir. La contraseña de bloqueo se almacena junto con información de bloqueo adicional en un servicio 306 de revocación del sistema 300 informático emisor. La información de bloqueo comprende además, por ejemplo, un hash de una ID restringida del token de ID. En particular, por ejemplo, en el servicio de revocación no se almacena ninguna información de identificación personal.

En el paso 9, el programa 302 emisor del sistema 300 informático emisor genera una solicitud de conexión para establecer un canal de comunicación cifrado entre el programa 302 emisor del sistema 300 informático y la cartera 102 de identificación del terminal 100 móvil. El programa emisor muestra esta solicitud de conexión al usuario 10, por ejemplo, actualizando la información en el sitio web del navegador 106 mostrado. Además, la contraseña de bloqueo se muestra al usuario 10. En el paso 9a, el usuario 10 puede abrir la solicitud de conexión mostrada en el navegador usando un botón en su cartera 102 de identificación, es decir, la cartera 102 de identificación puede establecer el canal de comunicación cifrado correspondiente con el programa 302 emisor. Por ejemplo, la solicitud de conexión también se puede mostrar en el navegador como un código legible por máquina, por ejemplo, un código QR.

En el paso 10, la cartera 102 de identificación muestra al usuario 10 detalles de la solicitud de conexión recibida a través del navegador. El usuario puede confirmar esta solicitud de conexión, después de lo cual la cartera 102 de identificación establece el canal de comunicación cifrado con el programa 302 emisor. El canal de comunicación cifrado correspondiente es, por ejemplo, un canal DIDCom. En este caso, la solicitud de conexión es una invitación DIDCom. En el curso de la configuración del canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor, la cartera 102 de identificación se autentica mutuamente ante el programa 302 emisor y el programa proveedor de ID se autentica ante la cartera 102 de identificación.

Si el canal de comunicación cifrado se configura entre la cartera 102 de identificación y el programa 302 emisor, el programa 302 emisor envía la credencial digital verificable creada con los atributos de usuario leídos a la cartera 102 de identificación a través del canal de comunicación cifrado en el paso 11., por ejemplo, , el usuario recibe la credencial digital verificable recibida y puede aceptarla. Con su correspondiente aceptación, la credencial digital verificable se almacena en el área 104 de memoria protegida de la cartera 102 de identificación del terminal 100 móvil. Finalmente, por ejemplo, se eliminan los atributos de usuario leídos en el sistema informático emisor. Los atributos de usuario leídos también se eliminan en el sistema informático proveedor de ID.

La Figura 3 muestra un diagrama de flujo de otro método ejemplar para leer atributos de usuario del token 200 de ID usando el sistema 500 informático proveedor de ID y para emitir una credencial digital verificable con los atributos de usuario leídos por el sistema 300 informático emisor. El sistema 101 usado para esto corresponde, por ejemplo, al sistema 101 mostrado en la Figura 1, que ya se ha utilizado para Método según la Figura 2. En el caso del método según la Figura 3, el canal de comunicación cifrado se configura entre la cartera de identificación o el programa 102 de cartera del terminal 100 móvil y el programa 302 emisor del sistema 300 informático emisor antes de que se establezca el canal de comunicación cifrado para leer los atributos de usuario del token 200 de ID a través del sistema 500 informático proveedor de ID. Esta implementación alternativa puede tener la ventaja de hacer que el robo de datos sea más difícil. En el curso de la configuración del canal de comunicación cifrado entre el programa 102 de cartera y el programa 302 emisor, la cartera de identificación y el programa 302 emisor se autentican mutuamente, por lo tanto, el programa 302 emisor ya sabe en este momento con quién se está comunicando y a quién se envía la credencial digital verificable emitida al final del trámite. Esto evita que una credencial digital verificable generada sea redirigida después de su creación configurando el canal de comunicación cifrado a una cartera de identificación diferente a la cartera 102 de identificación del terminal 100 móvil, a través de la cual el usuario inicializó previamente el proceso. Al configurar el canal de comunicación cifrado entre la cartera 102 y el programa 302 emisor al comienzo del procedimiento, se autentican y determinan los participantes correspondientes en el procedimiento. Solo después de esta determinación se le permite al usuario 10 leer los atributos de usuario del token 200 de ID. De este modo se puede garantizar que el programa 102 de cartera, al que finalmente se envía la credencial digital verificable, sea una cartera 102 de identificación, que es autorizada por el usuario 10 para recibir la credencial digital verificable a expedir o que la introducción se realice con el consentimiento del usuario 10.

Inicialmente, el sistema 300 informático emisor del servicio emisor envía a la cadena 400 de bloques datos de identidad que identifican el servicio emisor. Los datos de identidad correspondientes comprenden, por ejemplo, una clave criptográfica pública del servicio emisor. Además se almacenan, por ejemplo, esquemas de datos de credenciales digitales verificables, que son emitidos por el servicio emisor. Los esquemas de datos correspondientes se almacenan, por ejemplo, junto con definiciones de credenciales, que definen los tipos de credenciales que emite el servicio emisor. Finalmente, la información de revocación, por ejemplo, también se almacena en la cadena 400 de bloques, que define cómo se revocan las credenciales emitidas por el servicio emisor.

En el paso 1, se inicia el proceso para emitir una credencial digital verificable para el usuario 10 utilizando el terminal 100 móvil. Para ello, el usuario 10 accede a un sitio web del servicio emisor, por ejemplo, utilizando el navegador 106 del terminal 100 móvil. La llamada puede, por ejemplo, exigir que el usuario 10 acepte las condiciones de protección de datos y de uso del servicio emisor. Alternativamente, este proceso también se puede iniciar utilizando un enlace proporcionado por la cartera de identificación. Si el usuario hace clic en el enlace correspondiente, se abre el sitio web del servicio emisor en el navegador 106 del terminal 100 móvil.

En el paso 2, el programa 302 emisor del sistema 300 informático emisor genera una solicitud de conexión para establecer un canal de comunicación cifrado entre el programa 302 emisor del sistema 300 informático y la cartera 102 de identificación del terminal 100 móvil. El programa emisor muestra esta solicitud de conexión al usuario 10, por ejemplo, actualizando la información en el sitio web mostrado del navegador 106. Además, la contraseña de bloqueo se muestra al usuario 10. En el paso 2a, el usuario 10 puede abrir la solicitud de conexión mostrada en el navegador usando un botón en su cartera 102 de identificación, es decir, la cartera 102 de identificación puede establecer el canal de comunicación cifrado correspondiente con el programa 302 emisor. Por ejemplo, la solicitud de conexión también se puede mostrar en el navegador como un código legible por máquina, por ejemplo, un código QR.

En el paso 3, la cartera 102 de identificación muestra al usuario 10 detalles de la solicitud de conexión recibida a través del navegador. El usuario puede confirmar esta solicitud de conexión, después de lo cual la cartera 102 de identificación configura el canal de comunicación cifrado con el programa proveedor de ID 302. El canal de comunicación cifrado correspondiente es, por ejemplo, un canal DIDCom. En este caso, la solicitud de conexión es una invitación DIDCom. En el curso de la configuración del canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor, la cartera 102 de identificación se autentica mutuamente en el programa 302 emisor y el programa proveedor de ID se autentica en la cartera 102 de identificación. De este modo, el usuario puede comprobar, por ejemplo, si está conectado con el emisor correcto.

En el paso 4, el usuario 10 inicia el proceso del proveedor de ID, es decir, la lectura de atributos de usuario del token 200 de ID por el sistema 500 informático proveedor de ID a través del terminal 100 móvil. El usuario inicia el proceso del proveedor de ID hacia el servicio emisor, es decir, el sistema informático emisor, que responde proporcionando una URL. Los parámetros se almacenan bajo la URL correspondiente para establecer un canal de comunicación cifrado entre el programa 108 cliente del terminal 100 móvil y el sistema 500 informático proveedor de ID. El navegador web llama a la URL correspondiente y proporciona los parámetros proporcionados a continuación al programa 108 cliente. La configuración del canal de comunicación cifrado está lista. El programa 108 cliente utiliza los parámetros proporcionados bajo la URL para iniciar el canal de comunicación cifrado con el sistema 500 informático proveedor de ID. En el paso 4a, el navegador 106 evalúa la respuesta del sistema 500 informático proveedor de ID y llama al programa 108 cliente.

En el paso 5, el programa 108 cliente proporciona información en un dispositivo de visualización del terminal 100 móvil, por ejemplo, en una pantalla, a la persona que lee o está autorizada para leer, es decir, el servicio proveedor de ID, los atributos de usuario solicitados por el servicio proveedor de ID y/o el uso previsto de los atributos de usuario que se van a leer. El usuario 10 puede comprobar la información mostrada y, si la acepta, introducir un PIN en el terminal 100 móvil a través de un dispositivo de entrada, por ejemplo, una pantalla configurada como pantalla táctil. El PIN correspondiente se envía al programa 108 cliente al token 200 de ID para su verificación. Si el PIN introducido es correcto, el programa 108 cliente establece una conexión entre el token 200 de ID y el sistema 500 informático proveedor de ID en forma de un canal de comunicación cifrado de extremo a extremo. El token de ID y el sistema informático proveedor de identificación pueden autenticarse entre sí a través de este canal de comunicación cifrado. Si la autenticación mutua tiene éxito y el sistema informático proveedor de ID puede demostrar la autorización de acceso para leer atributos de usuario del token 200 de ID, el sistema 500 informático proveedor de ID recibe acceso de lectura al token 200 de ID. La prueba de autorización correspondiente puede ser, por ejemplo, un certificado de lectura del servicio proveedor de ID.

En el paso 6, los atributos de usuario solicitados se transmiten desde el token 200 de ID al sistema 500 informático proveedor de ID a través del canal de comunicación cifrado entre el token 200 de ID y el sistema 500 informático proveedor de ID.

En el paso 7, el sistema 500 informático proveedor de ID responde al programa 108 cliente con una URL de redireccionamiento después de que los atributos del usuario se hayan leído con éxito. Esta URL de redireccionamiento comprende una sesión del proveedor de ID correspondiente al identificador, durante la cual se leyeron los atributos del usuario. El programa 108 cliente pasa la URL de redireccionamiento al navegador. En el paso 5a, el navegador 106 llama a la URL de redireccionamiento y, por lo tanto, proporciona al sistema 300 informático emisor información de que el proceso de lectura con la sesión del proveedor de ID especificada fue exitosa y al sistema 500 informático proveedor de ID los atributos de usuario que se van a leer del token 200 de ID presentes.

En el paso 8, el sistema 300 informático emisor solicita la lectura de los atributos del usuario desde el sistema 500 informático proveedor de ID cuando se invoca la URL de redireccionamiento. Para este propósito, por ejemplo, se establece un canal de comunicación cifrado, como un canal TLS, entre el sistema 300 informático emisor y el sistema 500 informático proveedor de ID. El sistema 300 informático emisor solicita la lectura de atributos de usuario desde el sistema 500 informático proveedor de ID, por ejemplo, utilizando el programa 304 de utilidad.

En el paso 9, en respuesta a la solicitud del sistema 300 informático emisor, el sistema 500 informático proveedor de ID envía los atributos de usuario leídos al sistema 300 informático emisor a través del canal de comunicación cifrado entre el sistema 500 informático proveedor de ID y el sistema 300 informático emisor. Los atributos de usuario leídos se firman, por ejemplo, a través del sistema 500 informático proveedor de ID con una clave de firma del sistema 500 informático proveedor de ID. La autenticidad de los atributos de usuario leídos es confirmada por el sistema 500 informático proveedor de ID mediante la firma correspondiente.

En el paso 10, el sistema 300 informático emisor o el programa 302 emisor, que está instalado en el sistema 300 informático emisor, genera una contraseña de bloqueo para revocar la credencial digital verificable que se va a emitir. La contraseña de bloqueo se almacena junto con información de bloqueo adicional en un servicio 306 de revocación del sistema 300 informático emisor. La información de bloqueo comprende además, por ejemplo, un hash de una ID restringida del token de ID. En particular, por ejemplo, en el servicio de revocación no se almacena ninguna información de identificación personal.

En el paso 11, el programa 302 emisor envía la credencial digital verificable creada con los atributos de usuario leídos a la cartera 102 de identificación a través del canal de comunicación cifrado. Por ejemplo, se muestra al usuario la credencial digital verificable recibida y puede aceptarla. Según la suposición correspondiente, la credencial digital verificable se almacena en el área 104 de memoria protegida de la cartera 102 de identificación del terminal 100 móvil. Finalmente, por ejemplo, se eliminan los atributos de usuario leídos en el sistema informático emisor. Los atributos de usuario leídos también se eliminan en el sistema informático proveedor de ID.

La Figura 4 muestra un sistema 101 para emitir una credencial digital verificable usando atributos de usuario que se leen desde un token 200 de ID. El sistema 100 mostrado en la Figura 4 corresponde esencialmente al sistema 100 mostrado en la Figura 1. El sistema mostrado en la Figura 4 difiere del sistema 100 mostrado en la Figura 1 solo en que el programa 108 cliente ahora está incluido en la cartera 102 de identificación. Además, en el caso de esta realización del sistema 101, no se utiliza ningún navegador para llevar a cabo el método. Por supuesto, el terminal 100 móvil puede incluir un navegador, pero éste no se utiliza en el presente método. Por lo tanto, el procedimiento correspondiente también podría realizarse mediante un terminal 100 móvil que no tenga navegador. Un programa 108 cliente integrado en la cartera 102 de identificación para proporcionar acceso de lectura a un token ID 200 a través del sistema 500 informático proveedor de ID puede tener la ventaja de que el usuario no tiene que instalar ningún componente además de la cartera 102 de identificación en su terminal 100 móvil. El programa cliente correspondiente ya existe y lo proporciona la cartera 102 de identificación. Además, se puede aumentar la seguridad porque la comunicación entre diferentes programas, que se instalan independientemente uno de otro, se realiza a través del terminal 100 móvil. Además, no utilizar un navegador puede tener la ventaja de que aumenta la seguridad porque no hay cambio de contexto a través del navegador entre el programa cliente y la cartera 102 de identificación.

La Figura 5 muestra un diagrama de flujo de un método ejemplar para leer atributos de usuario de un token 200 de ID por un sistema 500 informático proveedor de ID y un uso de los atributos de usuario leídos por un sistema 300 informático emisor para generar una credencial digital verificable para una cartera 102 de identificación en un terminal 100 móvil. Para llevar a cabo el procedimiento según la Figura 5 se utiliza, por ejemplo, el sistema 100 según la Figura 4.

En el paso 1, el usuario inicia el proceso para emitir la credencial digital verificable desde la cartera 102 de identificación. Por ejemplo, el usuario llama a la cartera 102 de identificación, que le proporciona un botón en un dispositivo de salida del terminal 100 móvil, por ejemplo, una pantalla, para emitir una credencial digital verificable correspondiente, por ejemplo, “Emitir ID maestra”. Si el usuario 10 hace clic en el botón mostrado, la cartera de identificación inicia una llamada API a la cartera de identificación, con la cual envía una solicitud de emisión al sistema 300 informático emisor.

En el paso 2, el sistema informático emisor responde al usuario que inicia el proceso de conversión proporcionando una URL. Los parámetros se almacenan bajo la URL correspondiente para establecer un canal de comunicación cifrado entre el programa 108 cliente del terminal 100 móvil y el sistema 500 informático proveedor de ID. La cartera 102 de identificación llama la URL correspondiente y proporciona los parámetros proporcionados a continuación al programa 108 cliente listo para configurar el canal de comunicación cifrado. El programa 108 cliente utiliza los parámetros proporcionados en la URL para iniciar el canal de comunicación cifrado con el sistema 500 informático proveedor de ID.

En el paso 5, el sistema 500 informático proveedor de ID responde al programa 108 cliente con una URL de redireccionamiento después de que los atributos del usuario se hayan leído con éxito. Esta URL de redireccionamiento comprende una sesión del proveedor de ID correspondiente al identificador, durante la cual se leyeron los atributos del usuario. El programa 108 cliente llama al punto final API de la URL de redireccionamiento y, por lo tanto, proporciona al sistema 300 informático emisor información de que el proceso de lectura con la sesión del proveedor de ID especificada fue exitoso y que el sistema 500 informático proveedor de ID ha recibido los atributos de usuario para ser leídos del token 200 de ID.

En el paso 9, el programa 302 emisor del sistema 300 informático emisor genera una solicitud de conexión para establecer un canal de comunicación cifrado entre el programa 302 emisor del sistema 300 informático y la cartera 102 de identificación del terminal 100 móvil. El sistema 300 informático emisor envía esta solicitud de conexión a la cartera 102 de identificación en respuesta a la llamada API.

En el paso 10, la cartera 102 de identificación muestra al usuario 10 detalles de la solicitud de conexión recibida. El usuario puede confirmar esta solicitud de conexión, después de lo cual la cartera 102 de identificación establece el canal de comunicación cifrado con el programa 302 emisor. El canal de comunicación cifrado correspondiente es, por ejemplo, un canal DIDCom. En este caso, la solicitud de conexión es una invitación DIDCom. En el curso de la configuración del canal de comunicación cifrado entre la cartera 102 de identificación y el sistema 302 informático emisor, la cartera 102 de identificación se autentica mutuamente en el programa 302 emisor y el programa proveedor de ID se autentica en la cartera 102 de identificación.

Si el canal de comunicación cifrado se configura entre la cartera 102 de identificación y el programa 302 emisor, el programa 302 emisor envía la credencial digital verificable creada con los atributos de usuario leídos a la cartera 102 de identificación a través del canal de comunicación cifrado en el paso 11., por ejemplo, , el usuario recibe la credencial digital verificable recibida y puede aceptarla. Además, por ejemplo, la contraseña de bloqueo se transmite a la cartera 102 de identificación. Según la suposición correspondiente, la credencial digital verificable se almacena en el área 104 de memoria protegida de la cartera 102 de identificación del terminal 100 móvil. Finalmente, por ejemplo, se eliminan los atributos de usuario leídos en el sistema informático emisor. Los atributos de usuario leídos también se eliminan en el sistema informático proveedor de ID.

La Figura 6 muestra un sistema 101 ejemplar para emitir una credencial digital verificable utilizando atributos de usuario que se leen desde un token 200 de ID. El sistema 101 mostrado en la Figura 6 corresponde esencialmente al sistema 101 mostrado en la Figura 4. El sistema 101 mostrado en la Figura 6 difiere del sistema 101 mostrado en la Figura 4 en que el programa informático de identificación está integrado en el sistema 300 informático emisor. Para este propósito, el sistema 300 informático emisor comprende, por ejemplo, un programa 305, que comprende el programa de utilidad para iniciar una lectura de atributos de usuario y un programa proveedor de ID para leer realmente los atributos de usuario del token 200 de ID. Tal estructura de sistema puede tener la ventaja de que hace posible que el canal de comunicación cifrado lea atributos de usuario del token de ID mediante el programa proveedor de ID 305 dentro de un canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor, a través del cual se transmite la credencial digital y verificable. Puede ser especialmente ventajoso en este caso que durante la configuración del canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor tenga lugar una autenticación mutua de la cartera 102 de identificación y el programa 302 emisor. De este modo, se puede implementar una vinculación de canal criptográfico del canal de transmisión para transmitir los atributos del usuario al canal para proporcionar la credencial digital verificable a través del cual se tuneliza el canal de lectura. Además de la vinculación del canal, el canal de transmisión también está vinculado a la cartera 102 de identificación y al programa 302 emisor mediante autenticación. Para este propósito, se utiliza el canal de comunicación cifrado entre la cartera 102 de identificación y el programa 302 emisor para leer los atributos de usuario del token 200 de ID antes de que se establezca el canal de comunicación cifrado.

La Figura 7 muestra un diagrama de flujo de un método ejemplar para leer atributos de usuario del token 200 de ID mediante un programa proveedor de ID 305 integrado en el sistema 300 informático emisor de una credencial digital verificable por el sistema 300 informático emisor, que comprende los atributos de usuario leídos. Para la realización del procedimiento se utiliza, por ejemplo, el sistema 100 según la Figura 6.

En el paso 2, el programa 302 emisor del sistema 300 informático emisor genera una solicitud de conexión para establecer un canal de comunicación cifrado entre el programa 302 emisor del sistema 300 informático y la cartera 102 de identificación del terminal 100 móvil. El sistema 300 informático emisor envía esta solicitud de conexión a la cartera de identificación en respuesta a la llamada API.

En el paso 3, la cartera 102 de identificación muestra al usuario 10 detalles de la solicitud de conexión recibida. El usuario puede confirmar esta solicitud de conexión, después de lo cual la cartera 102 de identificación establece el canal de comunicación cifrado con el programa 302 emisor. El canal de comunicación cifrado correspondiente es, por ejemplo, un canal DIDCom. En este caso, la solicitud de conexión es una invitación DIDCom. En el curso de la configuración del canal de comunicación cifrado entre la cartera 102 de identificación y el sistema 302 informático emisor, la cartera 102 de identificación se autentica mutuamente en el programa 302 emisor y el programa proveedor de ID se autentica en la cartera 102 de identificación. El usuario puede así comprobar, por ejemplo, si está conectado con el emisor correcto.

En el paso 4, el sistema informático emisor envía un canal de comunicación cifrado mediante URL, por ejemplo, un canal DIDComm. Los parámetros se almacenan bajo la URL correspondiente para establecer un canal de comunicación cifrado entre el programa 108 cliente del terminal 100 móvil y el sistema 500 informático proveedor de ID. La cartera 102 de identificación llama a la URL correspondiente y proporciona los parámetros proporcionados a continuación al programa 108 cliente listo para configurar el canal de comunicación cifrado. El programa 108 cliente utiliza los parámetros proporcionados en la URL para iniciar el canal de comunicación cifrado con el sistema 500 informático proveedor de ID.

En el paso 5, el programa 108 cliente indica en un dispositivo de visualización del terminal 100 móvil, por ejemplo, en una pantalla, la persona que lee o la persona autorizada para leer, es decir, el servicio proveedor de ID, los atributos de usuario solicitados por el servicio proveedor de ID. y/o el Propósito de los atributos del usuario a leer. El usuario 10 puede comprobar la información mostrada y, si la acepta, introducir un PIN en el terminal 100 móvil a través de un dispositivo de entrada, por ejemplo, una pantalla configurada como pantalla táctil. El PIN correspondiente se envía al programa 108 cliente al token 200 de ID para su verificación. Si el PIN introducido es correcto, el programa 108 cliente establece una conexión entre el token 200 de ID y el sistema 500 informático proveedor de ID en forma de un canal de comunicación cifrado de extremo a extremo. Este canal y, por tanto, todos los datos transmitidos a través de este canal se canalizan a través del canal cifrado previamente establecido, como, por ejemplo, un canal DIDComm. El token de ID y el sistema informático proveedor de identificación pueden autenticarse entre sí a través de este canal de comunicación cifrado y tunelizado. Si la autenticación mutua tiene éxito y el sistema informático proveedor de ID puede demostrar la autorización de acceso para leer atributos de usuario del token 200 de ID, el sistema 500 informático proveedor de ID recibe acceso de lectura al token 200 de ID. La prueba de autorización correspondiente puede ser, por ejemplo, un certificado de lectura del servicio proveedor de ID.

En el paso 4, los atributos de usuario solicitados se transmiten desde el token 200 de ID al sistema 500 informático proveedor de ID a través del canal de comunicación cifrado y tunelizado entre el token 200 de ID y el sistema 500 informático proveedor de ID.

En el paso 7, el sistema 300 informático emisor o el programa 302 emisor, que está instalado en el sistema 300 informático emisor, genera una contraseña de bloqueo para revocar la credencial digital verificable que se va a emitir. La contraseña de bloqueo se almacena junto con información de bloqueo adicional en un servicio 306 de revocación del sistema 300 informático emisor. La información de bloqueo comprende además, por ejemplo, un hash de una ID restringida del token de ID. En particular, por ejemplo, en el servicio de revocación no se almacena ninguna información de identificación personal.

En el paso 8, el programa 302 emisor envía la credencial digital verificable creada con los atributos de usuario leídos a la cartera 102 de identificación a través del canal de comunicación cifrado, que es, por ejemplo, un canal de comunicación DID. Se muestra al usuario, por ejemplo, la credencial digital verificable recibida y puede aceptarla. Además, a través de este canal de comunicación cifrado se transmite, por ejemplo, la contraseña de Spear. Según la suposición correspondiente, la credencial digital verificable se almacena en el área 104 de memoria protegida de la cartera 102 de identificación del terminal 100 móvil. Finalmente, por ejemplo, se eliminan los atributos de usuario leídos en el sistema informático emisor. Los atributos de usuario leídos también se eliminan en el sistema informático proveedor de ID.

La Figura 8 ilustra un uso de una credencial 110 digital verificable, que fue emitida, por ejemplo, según uno de los métodos de las Figuras 2, 3, 5 o 7. El usuario 10 tiene un terminal 100 móvil, por ejemplo, un teléfono inteligente, en el que la credencial 110 digital verificable está almacenada de forma segura en una cartera de identificación. El usuario 10 recibe la credencial 110 digital verificable correspondiente de un emisor 300. El usuario 10 puede usar la credencial digital verificable emitida de esta manera para un verificador 600. Para ello, el usuario 10 envía la credencial 110 digital verificable, por ejemplo, desde su terminal 100 móvil, a un sistema 600 informático de verificación del verificador. Este verifica la credencial 110 digital verificable proporcionada usando una infraestructura SSI, que comprende una cadena 400 de bloques. Por ejemplo, la información 402 de autenticación para autenticar al emisor 300 y al verificador 600 se almacena en la cadena 400 de bloques. Además, por ejemplo, las claves 404 criptográficas públicas del emisor 300 se almacenan en la cadena de bloques, y su uso como clave de verificación de firma permite verificar una firma de la credencial 110 digital verificable. Además, en la cadena 400 de bloques se almacenan, por ejemplo, esquemas 406 de datos que definen las estructuras de las credenciales 110 digitales verificables. Utilizando el esquema 406 de datos almacenado, se puede comprobar si la credencial 110 digital verificable tiene la estructura de datos deseada y, en particular, si la credencial 110 digital verificable comprende los atributos de usuario que debería incluir. Además, los datos 408 de revocación se pueden almacenar en la cadena 400 de bloques, que define la revocación de una credencial digital verificable emitida. Por ejemplo, se puede almacenar en la cadena 400 de bloques donde se puede almacenar un aviso de revocación correspondiente de una credencial digital verificable o un aviso de revocación correspondiente en la cadena 400 de bloques. Por tanto, la validez de una credencial 110 digital verificable presentada puede comprobarse mediante un sistema 600 informático de verificación utilizando la cadena 400 de bloques. Si la verificación de validez es positiva y se verifica así la credencial, los datos proporcionados por ella, en particular los atributos del usuario, son aceptados por el sistema 600 informático de verificación como auténticos. Por lo tanto, el usuario 10 también puede identificarse de este modo ante el sistema 600 informático de verificación mediante la credencial digital verificable. La cadena 400 de bloques, por ejemplo, es una cadena de bloques pública que requiere autorización, en la que el acceso de escritura, por ejemplo, por parte del sistema 300 informático emisor, solo con la correspondiente prueba de autorización y cualquiera, como, por ejemplo, el sistema 600 informático de control, puede leer el cadena 400 de bloques con sus entradas.

La Figura 9, que consta de las Figuras 9A y 9B, muestra un sistema 101 ejemplar para emitir y proporcionar una credencial digital verificable utilizando atributos de usuario que se leen desde un token 200 de ID. Basado en el sistema 101 de la Figura 9, se puede implementar cada uno de los sistemas 101 según las Figuras 1, 4 y 6. El sistema 101 mostrado en la Figura 9 se puede utilizar para llevar a cabo cualquiera de los métodos ejemplares de las Figuras 2, 3, 5 y 7. El sistema 101 ejemplar mostrado en la Figura 9 comprende un terminal 100 móvil, un token 200 de ID, un sistema 300 informático emisor, un sistema 500 informático proveedor de ID y una red 450 de cadenas de bloques, que proporciona una cadena 400 de bloques.

El terminal 100 móvil, que es, por ejemplo, un teléfono inteligente, comprende una memoria 112 con programas 114. Estos programas 104 comprenden, por ejemplo, una cartera de identificación. Además, estos programas 104 pueden incluir, por ejemplo, un programa cliente y/o. Además, la memoria 112 comprende, por ejemplo, un área de memoria protegida que está asignada a la cartera de identificación y en la que se almacenan credenciales digitales verificables de la cartera de identificación. Un procesador 116 está configurado para controlar el terminal 100 móvil para emitir la credencial digital verificable y para proporcionar la credencial digital verificable emitida en la cartera de identificación tras la ejecución de las instrucciones 118 de programa que proporcionan los programas 114. Para ello, el terminal 100 móvil comprende además una interfaz 120 de comunicación para la comunicación con el token 200 de ID, en particular sin contacto, por ejemplo, a través de NFC. Además, el terminal 100 móvil también comprende una interfaz 122 de comunicación para comunicación a través de la red 150, como Internet. Por ejemplo, el terminal 100 móvil se comunica con el sistema 300 informático emisor y/o el sistema 500 informático proveedor de ID utilizando la interfaz 122 de comunicación. Finalmente, el terminal 100 móvil comprende una interfaz 124 de usuario para que un usuario interactúe con el terminal 100 móvil. Por ejemplo, la interfaz 124 de usuario comprende un dispositivo de entrada y un dispositivo de salida, por ejemplo, una pantalla táctil. Utilizando el dispositivo de entrada, el usuario puede introducir datos y comandos en el terminal 100 móvil. Usando el dispositivo de salida, el terminal 100 móvil puede mostrar datos al usuario. Por ejemplo, la interfaz 124 de usuario está configurada para recibir datos de autenticación para autenticar al usuario en el token 200 de ID. Por ejemplo, la interfaz 124 de usuario comprende uno o más sensores, como una cámara o un escáner de huellas dactilares, para capturar uno o más datos de autenticación biométrica para autenticar al usuario.

El token 200 de ID comprende una memoria 202 con un área 202 de memoria protegida en la que se almacenan los atributos 206 de usuario de un usuario al que está asignado el token 200 de ID. La lectura de los atributos 206 de usuario requiere, por ejemplo, una prueba exitosa de autorización de lectura, por ejemplo, a través de un certificado de lectura correspondiente de una infraestructura PKI. Además, el token de ID comprende un procesador 208, que controla la lectura de los atributos 206 de usuario ejecutando las instrucciones 210 de programa. Finalmente, el token 200 de ID comprende una interfaz 212 de comunicación para comunicarse con el terminal 100 móvil, por ejemplo, a través de NFC.

El sistema 300 informático emisor está configurado para emitir credenciales digitales verificables. En particular, el sistema 300 informático emisor está configurado para iniciar una lectura de los atributos 206 de usuario del token 200 de ID utilizando el sistema 500 informático proveedor de ID para emitir la credencial digital verificable. Los programas 314 se almacenan en una memoria 312 del sistema 300 informático emisor. Estos programas comprenden, por ejemplo, un programa emisor para emitir las credenciales digitales verificables, un programa de utilidad para controlar la lectura de los atributos 206 de usuario del token 200 de ID y/o un programa de revocación para revocar las credenciales digitales verificables emitidas. Por ejemplo, los programas 314 pueden incluir adicionalmente un programa proveedor de ID, mediante el cual el sistema 500 informático proveedor de ID y sus funciones pueden integrarse en el sistema 300 informático emisor. También se almacena una clave 318 criptográfica pública en la memoria 318 como clave de verificación de firma del sistema 300 informático emisor. Una clave 322 criptográfica privada asociada como clave de firma del sistema 300 informático emisor para firmar credenciales digitales verificables se almacena, por ejemplo, en un área 320 de memoria protegida de la memoria 312. Además, el sistema 300 informático emisor comprende un procesador 324, que está configurado para ejecutar las instrucciones 326 de programa de los programas 314. Al ejecutar las instrucciones 326 de programa mediante el procesador 324, se controla el sistema 300 informático emisor para emitir credenciales digitales verificables. Para este propósito, el sistema informático emisor comprende además una interfaz 328 de comunicación para la comunicación a través de la red 150, por ejemplo, con el terminal 100 móvil, la red 450 de cadenas de bloques y/o el sistema 500 informático proveedor de ID.

El sistema 500 informático proveedor de ID está configurado para leer los atributos 206 de usuario del token 206 de ID. Para ello comprende en su memoria 512 un certificado 516 de lectura de una PKI para acreditar la autorización de lectura. Alternativamente, la funcionalidad de lectura para leer los atributos 206 de usuario del token 206 de ID también podría integrarse en el sistema 300 informático emisor. En este caso, el sistema 300 informático emisor incluiría en su memoria 312 un certificado de lectura de PKI correspondiente emitido al sistema informático emisor. Además, los programas 314 del sistema 300 informático emisor incluirían un programa proveedor de ID para leer los atributos del usuario. Esto significaría que el sistema 500 informático proveedor de ID o su funcionalidad estaría integrado en el sistema informático emisor y el sistema 101 no incluiría un sistema 500 informático proveedor de ID independiente.

Alternativamente, el sistema 101 comprende un sistema 500 informático proveedor de ID independiente con una memoria 512, que comprende además programas 514, como un programa proveedor de ID, para leer atributos de usuario a partir de tokens de ID. Además, la memoria 512 comprende, por ejemplo, una clave 518 criptográfica pública y una clave 522 criptográfica privada asociada del sistema 500 informático proveedor de ID, almacenada en un área 520 de memoria protegida de la memoria 512. Por ejemplo, el certificado 516 de lectura se asigna a la clave 518 criptográfica pública del sistema 500 informático proveedor de ID, de modo que el sistema 500 informático proveedor de ID pueda demostrar, por ejemplo, en el curso de un procedimiento de desafío-respuesta, utilizando la clave 522 criptográfica privada que es el titular autorizado del certificado 516 de lectura. Para llevar a cabo la lectura de los atributos 206 de usuario del token 200 de ID, el sistema 500 informático proveedor de ID comprende un procesador 524, que controla el sistema 500 informático proveedor de ID ejecutando instrucciones 526 de programa de los programas 514. Finalmente, el sistema 500 informático proveedor de ID comprende una interfaz 528 de comunicación para comunicación a través de la red 150, por ejemplo, para leer los atributos 206 de usuario a través del terminal 100 móvil desde el token 200 de ID y/o para reenviar los atributos 206 de usuario leídos al sistema 300 informático emisor.

Finalmente, el sistema 101 comprende la red 450 de cadenas de bloques de una infraestructura SSI, que proporciona una cadena 400 de bloques. La cadena 400 de bloques, por ejemplo, es una cadena de bloques pública que requiere permiso y es gestionada por la red 450 de cadenas de bloques como un registro distribuido. La red 450 de cadenas de bloques comprende una pluralidad de servidores 412, 432 de cadenas de bloques en cada uno de los cuales, por ejemplo, se almacena una copia de la cadena 400 de bloques en una memoria 418, 438 correspondiente. Los servidores 412, 432 de cadenas de bloques comprenden cada uno un procesador 414, 434 para ejecutar instrucciones 416, 436 de programa de los programas 419, 439 para gestionar la cadena 400 de bloques. Finalmente, los servidores 412, 432 de cadenas de bloques comprenden cada uno una interfaz 420, 440 de comunicación para comunicarse a través de la red 150, por ejemplo, con el sistema 300 informático emisor.

Lista de signos de referencia

10 Usuario

100 Terminal móvil

101 Sistema

102 Cartera de identificación

104 Área de memoria protegida

106 Navegador

108 Programa cliente

112 Memoria

114 Programas

116 Procesador

118 Instrucciones de programa

120 Interfaz de comunicación

122 Interfaz de comunicación

124 Interfaz de usuario

150 Red

200 Token de ID

202 Memoria

204 Área de memoria protegida

206 Atributos de usuario

208 Procesador

210 Instrucciones de programa

212 Interfaz de comunicación

300 Sistema informático emisor

302 Programa emisor

304 Programa de utilidad

305 Programa de utilidad/Programa proveedor de ID

306 Programa de revocación

312 Memoria

314 Programas

318 Clave criptográfica pública

320 Área de memoria protegida

322 Clave criptográfica privada

324 Procesador

326 Instrucciones de programa

328 Interfaz de comunicación

400 Cadena de bloques

402 Datos de autentificación

404 Clave criptográfica pública

406 Esquemas de datos

408 Datos de revocación

412 Servidor de cadenas de bloques

414 Memoria

416 Procesador

418 Instrucciones de programa

419 Programas

420 Interfaz de comunicación

432 Servidor de cadenas de bloques

434 Memoria

436 Procesador

438 Instrucciones de programa

439 Programas

440 Interfaz de comunicación

450 Red de cadenas de bloques

500 Sistema informático proveedor de ID

512 Memoria

514 Programas

516 Certificado de lectura

518 Clave criptográfica pública

520 Área de memoria protegida

522 Clave criptográfica privada

524 Procesador

526 Instrucciones de programa

528 Interfaz de comunicación

Claims

REIVINDICACIONES

1. Método para leer uno o más atributos (206) de usuario de un token de ID, usando un sistema (500) informático proveedor de ID de un servicio proveedor de ID y proporcionando una credencial digital verificable con los atributos (206) de usuario leídos en una cartera (102) de identificación digital de un terminal (100) móvil usando un sistema (300) informático emisor de un servicio emisor de una infraestructura SSI,

en el que los atributos (206) de usuario de un usuario (10) se almacenan en un área (204) de memoria protegida de una memoria (202) del token (200) de ID,

en el que la infraestructura SSI comprende una cadena (400) de bloques en la que se almacenan un esquema (406) de datos para la credencial digital verificable y una clave (318, 404) criptográfica pública asociada con el servicio emisor, utilizándose el esquema (406) de datos como plantilla para verificar la credencial digital verificable, utilizándose la clave (318, 404) criptográfica pública del servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave (322) criptográfica privada del servicio emisor asociado con la clave de verificación de firma como clave de firma,

comprendiendo el método:

• el envío de una solicitud de emisión para emitir la credencial digital verificable desde el terminal (100) móvil a través de una red (150) al sistema (300) informático emisor para iniciar la lectura de los atributos (206) de usuario por parte del sistema (500) informático proveedor de ID del token (200) de ID,

• el permiso de acceso de lectura del sistema (500) informático proveedor de ID a los atributos (206) de usuario en el token (200) de ID a través del terminal (100) móvil y la red (150) para reenviar los atributos (206) de usuario leídos al sistema (300) informático emisor,

• la recepción de la credencial digital verificable emitida por el servicio emisor mediante la cartera (102) de identificación digital del terminal (100) móvil del sistema (300) informático emisor a través de la red (150), estableciéndose la credencial digital verificable de acuerdo con el esquema (406) de datos proporcionado en la cadena (400) de bloques, comprendiendo los atributos (206) de usuario leídos y estando firmado usando la clave (322) de firma del servicio emisor,

• el almacenaje de la credencial digital verificable recibida en la cartera (102) de identificación del terminal (100) móvil.

2. Método según la reivindicación 1, en el que permitir el acceso de lectura del sistema (500) informático proveedor de ID comprende:

• autenticar al usuario (10) con respecto al token (200) de ID usando el terminal (100) móvil,

• autenticar el sistema (500) informático proveedor de ID con respecto al token (200) de ID a través del terminal (100) móvil usando un certificado (516) de lectura basado en PKI del sistema (500) informático proveedor de ID para leer los atributos (206) de usuario del token (200) de ID,

• tras la autenticación exitosa del usuario (10) y el sistema (500) informático proveedor de ID con respecto al token (200) de ID, habilitar el acceso de lectura del sistema (500) informático proveedor de ID.

3. Método según cualquiera de las reivindicaciones anteriores, en el que el terminal (100) móvil establece un primer canal de comunicación cifrado a través de la red (150) con el sistema (300) informático emisor, a través del cual se envía la solicitud de emisión.

en el que el primer canal de comunicación cifrado es, por ejemplo, un canal TLS.

4. Método según cualquiera de las reivindicaciones anteriores, en el que el terminal (100) móvil comprende además un programa (108) cliente, a través del cual se realiza el acceso de lectura del sistema (500) informático proveedor de ID al token (200) de ID, en el que el acceso de lectura del sistema (500) informático proveedor de ID al token (200) de ID tiene lugar a través de un segundo canal de comunicación cifrado.

5. Método según la reivindicación 4, en el que el primer canal de comunicación cifrado lo establece el terminal (100) móvil utilizando un navegador (106) instalado en el terminal (100) móvil, en el que establecer el segundo canal de comunicación cifrado comprende:

• acceder a una página web del emisor utilizando el navegador (106), proporcionando la página web una URL para recuperar parámetros para establecer el segundo canal de comunicación cifrado para leer los atributos (206) del usuario,

• recuperar la URL usando el navegador (106),

• proporcionar los parámetros incluidos en la URL recuperada para el programa (108) cliente,

• establecer el segundo canal de comunicación cifrado a través del programa (108) cliente utilizando los parámetros proporcionados por la URL, o

en el que el primer canal de comunicación cifrado lo establece el terminal (100) móvil a través de la cartera (102) de identificación, en el que establecer el segundo canal de comunicación cifrado comprende:

• en respuesta a la solicitud de emisión, recibir la URL para recuperar parámetros para establecer el segundo canal de comunicación cifrado a través de la cartera (102) de identificación,

• recuperar la URL a través de la cartera (102) de identificación,

• establecer el segundo canal de comunicación cifrado a través del programa (108) cliente utilizando los parámetros proporcionados por la URL.

6. Método según cualquiera de las reivindicaciones 4 a 5, comprendiendo el método además establecer un tercer canal de comunicación cifrado entre la cartera (102) de identificación y el sistema (300) informático emisor, a través del cual la cartera (102) de identificación recibe la credencial digital verificable, en el que el establecimiento del tercer canal de comunicación cifrado comprende una autenticación mutua entre la cartera (102) de identificación y el sistema (300) informático emisor.

7. Método según la reivindicación 6, en el que el navegador (106) recibe una solicitud para establecer el tercer canal de comunicación cifrado, en el que la solicitud comprende uno o más parámetros de los sistemas (500) informáticos emisores para establecer el tercer canal de comunicación cifrado, y el navegador (106) proporciona la solicitud de la cartera (102) de identificación para establecer el tercer canal de comunicación cifrado.

8. Método según la reivindicación 7, en el que el navegador (106) recibe la solicitud para establecer el tercer canal de comunicación cifrado en respuesta a una lectura exitosa de los atributos (206) del usuario o

en el que el navegador (106) recibe la solicitud para establecer el tercer canal de comunicación cifrado en respuesta a la recuperación de la página web del servicio emisor, en el que un establecimiento exitoso del tercer canal de comunicación cifrado es un requisito previo para establecer el segundo canal de comunicación cifrado para leer los atributos (206) de usuario,

en el que la URL para establecer el segundo canal de comunicación cifrado se proporciona al navegador (106) del terminal (100) móvil, por ejemplo, solo después de establecer con éxito el tercer canal de comunicación cifrado.

9. Método según la reivindicación 6, en el que la cartera (102) de identificación comprende el programa (108) cliente, en el que la solicitud de emisión se envía utilizando el programa (108) cliente, en el que el primer canal de comunicación cifrado se establece entre la cartera (102) de identificación ) y el sistema (300) informático emisor,

en el que la solicitud de emisión se envía al sistema (300) informático emisor usando una llamada API, por ejemplo.

10. Método según la reivindicación 9, en el que la cartera (102) de identificación en respuesta a la solicitud de emisión recibe la solicitud para establecer un tercer canal de comunicación cifrado entre la cartera (102) de identificación y el sistema (300) informático emisor y establece el tercer canal de comunicación cifrado utilizando los parámetros proporcionados por la solicitud,

en el que un establecimiento exitoso del tercer canal de comunicación cifrado es un requisito previo para establecer el segundo canal de comunicación cifrado, que se establece como un subcanal cifrado en el tercer canal de comunicación.

11. Método según cualquiera de las reivindicaciones 6 a 10, en el que el tercer canal de comunicación cifrado es un canal DIDComm.

12. Método según cualquiera de las reivindicaciones anteriores, en el que el sistema (300) informático emisor comprende el sistema (500) informático proveedor de ID o

en el que el sistema (500) informático proveedor de ID es un sistema informático independiente del sistema (300) informático emisor,

en el que, por ejemplo, el sistema (500) informático proveedor de ID reenvía los atributos (206) de usuario leídos al sistema (300) informático emisor a través de un cuarto canal de comunicación cifrado.

13. Terminal (100) móvil para leer uno o más atributos (206) de usuario de un token (200) de ID y proporcionar una credencial digital verificable con los atributos (206) de usuario leídos en una cartera (102) de identificación digital del terminal (100) móvil, en el que la lectura se realiza a través del terminal (100) móvil usando un sistema (500) informático proveedor de ID de un servicio proveedor de ID, en el que la credencial digital verificable proporcionada es una credencial digital verificable emitida usando un sistema (300) informático emisor de un servicio emisor de una infraestructura SSI,

en el que la infraestructura SSI comprende una cadena (400) de bloques, en la que se almacenan un esquema (406) de datos para la credencial digital verificable y una clave (318, 404) criptográfica pública asociada con el servicio emisor, sirviendo el esquema (406) de datos como plantilla para verificar la credencial digital verificable, utilizándose la clave (318, 404) criptográfica pública del servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave (322) criptográfica privada del servicio emisor asociado a la clave de verificación de firma como clave de firma,

comprendiendo el terminal (100) móvil un procesador (116), una memoria (112) con instrucciones (118) de programa, una interfaz (120) de comunicación para comunicarse con el token (200) de ID y una interfaz (122) de comunicación para comunicarse a través de una red (150),

en el que la ejecución de las instrucciones (118) de programa por el procesador (116) del terminal (100) móvil hace que el procesador (116) controle el terminal (100) móvil para:

• enviar una solicitud de emisión para emitir la credencial digital verificable desde el terminal (100) móvil a través de la red (150) al sistema (300) informático emisor para iniciar la lectura de los atributos (206) de usuario por parte del sistema (500) informático proveedor de ID del token (200) de ID,

• permitir el acceso de lectura del sistema (500) informático proveedor de ID a los atributos (206) de usuario almacenados en un área (204) de memoria protegida de una memoria (202) del token (200) de ID a través del terminal (100) móvil y la red (150) para reenviar los atributos (206) de usuario leídos al sistema (300) informático emisor,

• recibir la credencial digital verificable emitida por el servicio emisor a través de la cartera (102) de identificación digital del terminal (100) móvil desde el sistema (300) informático emisor a través de la red (150), estableciéndose la credencial digital verificable de acuerdo con el esquema (406) de datos proporcionado en la cadena (400) de bloques, comprendiendo los atributos (206) de usuario leídos y estando firmada con la clave (322) de firma del servicio emisor,

• almacenar la credencial digital verificable recibida en la cartera (102) de identificación del terminal (100) móvil.

14. Sistema (300) informático emisor de un servicio emisor de una infraestructura SSI para leer uno o más atributos (206) de usuario de un token (200) de ID y proporcionar una credencial digital verificable con los atributos (206) de usuario leídos en una cartera (102) de identificación digital de un terminal (100) móvil, en el que la lectura se realiza a través del terminal (100) móvil usando un sistema (500) informático proveedor de ID de un servicio proveedor de ID,

en el que la infraestructura SSI comprende una cadena (400) de bloques, en la que se almacenan un esquema (406) de datos para la credencial digital verificable y una clave (318, 404) criptográfica pública asignada al servicio emisor, utilizándose el esquema (406) de datos como plantilla para verificar la credencial digital verificable, sirviendo la clave (318, 404) criptográfica pública del servicio emisor como clave de verificación de firma para verificar una firma de la credencial digital verificable, que se crea con una clave (322) criptográfica privada del servicio emisor asociado a la clave de verificación de firma como clave de firma,

en el que el sistema (300) informático emisor comprende un procesador (324), una memoria (312) con instrucciones (326) de programa y una interfaz (328) de comunicación para comunicarse a través de una red (150),

en el que una ejecución de las instrucciones (326) de programa por parte del procesador (324) del sistema (300) informático emisor hace que el procesador (324) controle el sistema (300) informático emisor para:

• recibir una solicitud de emisión para emitir la credencial digital verificable del terminal (100) móvil a través de la red (150),

• iniciar la lectura de los atributos (206) de usuario por parte del sistema (500) informático proveedor de ID desde un área (204) de memoria protegida de una memoria (202) del token (200) de ID en respuesta a la solicitud de emisión,

• recibir atributos (206) de usuario leídos a través del terminal (100) móvil y la red (150) desde el sistema (500) informático proveedor de ID,

• emitir la credencial digital verificable, que comprende los atributos (206) de usuario leídos, establecidos de acuerdo con el esquema (406) de datos proporcionado en la cadena (400) de bloques y firmado usando la clave (322) de firma del servicio emisor,

• enviar la credencial digital verificable emitida a través de la red (150) a esta cartera (102) de identificación del terminal (100) móvil.

15. Sistema (101) para leer uno o más atributos (206) de usuario de un token (200) de ID y proporcionar una credencial digital verificable con los atributos (206) de usuario leídos en una cartera (102) de identificación digital de un terminal (100) móvil. ) según la reivindicación 13 utilizando un sistema (300) informático emisor de un servicio emisor de una infraestructura SSI, en el que el sistema (300) informático emisor es un sistema informático emisor según la reivindicación 14 y la lectura por parte del sistema (300) informático emisor se realiza a través del terminal (100) móvil usando un sistema (500) informático proveedor de ID de un servicio proveedor de ID,

comprendiendo el sistema (101) además, por ejemplo, el sistema (500) informático proveedor de ID y/o la cadena (400) de bloques.