ES2961364T3 - Control del uso delegado de datos relativos a los identificadores descentralizados o DID - Google Patents

Control del uso delegado de datos relativos a los identificadores descentralizados o DID Download PDF

Info

Publication number
ES2961364T3
ES2961364T3 ES20735818T ES20735818T ES2961364T3 ES 2961364 T3 ES2961364 T3 ES 2961364T3 ES 20735818 T ES20735818 T ES 20735818T ES 20735818 T ES20735818 T ES 20735818T ES 2961364 T3 ES2961364 T3 ES 2961364T3
Authority
ES
Spain
Prior art keywords
related data
owner
party
data objects
computer system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES20735818T
Other languages
English (en)
Inventor
Brandon Murdoch
Ankur Patel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Application granted granted Critical
Publication of ES2961364T3 publication Critical patent/ES2961364T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)
  • Machine Translation (AREA)

Abstract

Las realizaciones divulgadas en el presente documento están relacionadas con sistemas informáticos y métodos para que un propietario de DID controle el uso delegado de datos relacionados con DID. Los permisos de delegación se adjuntan a objetos de datos relacionados con DID que proporciona el propietario del DID a una primera entidad de terceros. Los permisos de delegación especifican las interacciones que deben ocurrir entre el propietario de un DID y segundas entidades de terceros que reciben los objetos de datos relacionados con DID de la primera entidad de terceros. Los objetos de datos relacionados con DID se proporcionan a la primera entidad de terceros. Se reciben varias interacciones de segundas entidades de terceros que intentan utilizar los objetos de datos relacionados con DID. Las segundas entidades de terceros pueden utilizar los objetos de datos relacionados con DID cuando las interacciones recibidas satisfacen los permisos de delegación. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Control del uso delegado de datos relativos a los identificadores descentralizados o DID
Antecedentes
La mayoría de los documentos o grabaciones utilizados actualmente que prueban la identidad son emitidos por organizaciones centralizadas, tales como gobiernos, escuelas, empleadores u otros centros de servicios u organizaciones reguladoras. Estas organizaciones a menudo mantienen la identidad de cada miembro en un sistema de gestión de identidad centralizado. Un sistema de gestión de identidades centralizado es un sistema de información centralizado que se utiliza para que las organizaciones gestionen las identidades emitidas, su autenticación, autorización, roles y privilegios. Los sistemas centralizados de gestión de identidades se consideran seguros porque a menudo utilizan equipo físico informático (hardware) y equipo lógico informático (software) mantenidos profesionalmente. Típicamente, la organización emisora de identidad establece los términos y requisitos para registrar personas en la organización. Cuando una parte necesita verificar la identidad de la otra parte, la parte verificadora a menudo necesita pasar por el sistema centralizado de gestión de identidad para obtener información que verifique y/o autentique la identidad de la otra parte.
Los identificadores descentralizados (DID) son un nuevo tipo de identificador, y son independientes de cualquier registro centralizado, proveedor de identidad o autoridad de certificación. La tecnología de libro de asientos distribuido (tal como cadena de bloques) brinda la oportunidad de utilizar identificadores totalmente descentralizados. La tecnología de libro de asientos distribuido utiliza libros de asientos distribuidos globalmente para grabar transacciones entre dos o más partes de manera verificable. Una vez que se ha grabado una transacción, los datos de la sección del libro de asientos no se pueden alterar retroactivamente sin alterar todas las secciones posteriores del libro de asientos, lo que proporciona una plataforma bastante segura. Dado que un DID no está generalmente controlado por un sistema de gestión centralizado, sino que es propiedad del propietario de DID, a veces se hace referencia a los DID como identidades sin autoridad.
El objeto reivindicado en el presente documento no se limita a realizaciones que resuelven cualesquiera desventajas o que funcionan sólo en entornos tales como los descritos anteriormente. Más bien, estos antecedentes se proporcionan sólo para ilustrar un área de tecnología ejemplar con la que se pueden poner en práctica algunas realizaciones descritas en el presente documento.
El documento US2019230092A1 describe la generación y gestión de identificadores descentralizados de una entidad. Se graba un identificador descentralizado de una entidad en particular. Luego, al determinar que la entidad en particular está otorgando un permiso a otra entidad, el permiso se firma en base al identificador descentralizado grabado. Por ejemplo, el permiso puede firmarse mediante una clave privada del identificador descentralizado. El permiso puede verificarse previa solicitud autenticando el permiso firmado que está asociado con el identificador descentralizado grabado; y autorizar a la otra entidad a actuar sobre los datos dependiendo de la autenticación. Sólo como ejemplo, la autenticación puede producirse usando una clave pública asociada con el identificador descentralizado grabado.
El documento US2017272441A1 describe cómo el propietario o gestor de un recurso envía una solicitud a un servicio de gestión de permisos para crear una concesión de permisos que puede incluir la lista de acciones que un usuario puede realizar en un recurso. En consecuencia, el servicio de gestión de permisos puede crear la concesión de permisos y utilizar una clave criptográfica privada para firmar digitalmente la concesión de permisos creada. El servicio de gestión de permisos puede transmitir esta concesión de permisos firmada digitalmente, así como un certificado digital que comprenda una clave criptográfica pública para validar la concesión de permisos, a un recurso de destino. El recurso de destino puede usar la clave criptográfica pública para validar la firma digital de la concesión de permisos y determinar si un usuario está autorizado a realizar una o más acciones en base a, al menos en parte, una solicitud del usuario para realizar estas una o más acciones en el recurso.
Breve sumario
La invención se expone en el juego de reivindicaciones adjunto.
Este sumario se proporciona para presentar una selección de conceptos de una forma simplificada, describiéndose adicionalmente más adelante en la descripción detallada. Este sumario no pretende identificar características clave o características esenciales del objeto reivindicado, ni pretende ser utilizado como ayuda para determinar el alcance del objeto reivindicado.
Las realizaciones divulgadas en el presente documento están relacionadas con sistemas y métodos informáticos para que un propietario de DID controle el uso delegado de datos relativos a DID. Los permisos de delegación se adjuntan a objetos de datos relativos a DID que proporciona el propietario de DID a una primera entidad de terceros. Los permisos de delegación especifican las interacciones que deben producirse entre el propietario de DID y segundas entidades de terceros que reciben los objetos de datos relativos a DID de la primera entidad de terceros.
Los objetos de datos relativos a DID se proporcionan a la primera entidad de terceros. Se reciben diversas interacciones de segundas entidades de terceros que intentan utilizar los objetos de datos relativos a DID. Las segundas entidades de terceros pueden utilizar los objetos de datos relativos a DID cuando las interacciones recibidas satisfacen los permisos de delegación.
Características y ventajas adicionales se expondrán en la descripción que sigue, y en parte resultarán obvias a partir de la descripción, o pueden aprenderse mediante la práctica de las enseñanzas del presente documento. Las características y ventajas de la invención se pueden realizar y obtener por medio de los instrumentos y combinaciones particularmente indicados en las reivindicaciones adjuntas. Las características de la presente invención resultarán más evidentes a partir de la siguiente descripción y de las reivindicaciones adjuntas, o pueden aprenderse mediante la práctica de la invención como se establece de aquí en adelante.
Breve descripción de los dibujos
Para describir la manera en la que se pueden obtener las ventajas y características mencionadas anteriormente y otras, se realizará una descripción más particular del objeto brevemente descrito anteriormente haciendo referencia a realizaciones específicas que se ilustran en los dibujos adjuntos. Entendiendo que estos dibujos representan sólo realizaciones típicas, y que, por lo tanto, no deben considerarse limitantes en su alcance. Las realizaciones se describirán y explicarán con especificidad y detalles adicionales mediante el uso de los dibujos que se acompañan, en los que:
la figura 1 ilustra un sistema informático de ejemplo en el que se pueden emplear los principios descritos en el presente documento;
la figura 2 ilustra un entorno de ejemplo para crear una identificación descentralizada (DID);
la figura 3 ilustra un entorno de ejemplo para diversas operaciones y servicios de gestión de DID;
la figura 4 ilustra un dispositivo de almacenamiento descentralizado o concentradores de identidad de ejemplo; las figuras 5A y 5B ilustran una realización ejemplar de un entorno de sistema informático para que un propietario de DID controle el uso delegado de datos relativos a DID; y
la figura 6 ilustra un diagrama de flujo de un método de ejemplo para que un propietario de DID controle el uso delegado de datos relativos a DID.
Descripción detallada
Las realizaciones divulgadas en el presente documento están relacionadas con sistemas y métodos informáticos para que un propietario de DID controle el uso delegado de datos relativos a DID. Los permisos de delegación se adjuntan a objetos de datos relativos a DID que proporciona el propietario de DID a una primera entidad de terceros. Los permisos de delegación especifican las interacciones que deben producirse entre el propietario de DID y segundas entidades de terceros que reciben los objetos de datos relativos a DID de la primera entidad de terceros. Los objetos de datos relativos a DID se proporcionan a la primera entidad de terceros. Se reciben diversas interacciones de las segundas entidades de terceros que intentan utilizar los objetos de datos relativos a DID. A las segundas entidades de terceros se les permite utilizar los objetos de datos relativos a DID cuando las interacciones recibidas satisfacen los permisos de delegación.
Las realizaciones divulgadas en el presente documento representan un avance técnico con respecto a los sistemas existentes. Por ejemplo, un propietario de DID puede desear proporcionar sus objetos de datos relativos a DID, tal como vídeos, imágenes, documentos y similares, a una primera entidad de terceros que el propietario de DID conoce. Sin embargo, la primera entidad de terceros puede proporcionar posteriormente los objetos de datos relativos a DID a una o más segundas entidades de terceros sin el permiso del propietario de DID, quien puede no conocer a una o más segundas entidades de terceros. Adjuntar diversos permisos de delegación a los objetos de datos relativos a DID permite al propietario de DID conservar al menos algún nivel de control sobre los datos. El propietario de DID puede especificar qué tipos de información quiere recibir de la una o más entidades de terceros antes de que a estas entidades se les permita acceder a los datos relativos a DID. Esto aumenta la conveniencia y la productividad del usuario, ya que el propietario de DID y la una o más segundas entidades de terceros saben qué se espera si se van a utilizar los datos relativos a DID. La una o más segundas entidades de terceros no necesitan proporcionar información indeseada, lo que a su vez reduce la interacción innecesaria entre las partes, y, de este modo, ahorra tiempo y reduce el uso de recursos de procesamiento.
Debido a que los principios descritos en el presente documento pueden realizarse en el contexto de un sistema informático, se describirá un análisis introductorio de un sistema informático con respecto a la figura 1. Luego, esta descripción volverá a los principios de una plataforma de identificador descentralizado (DID) con respecto al resto de figuras.
Los sistemas informáticos adoptan cada vez más una amplia variedad de formas. Sistemas informáticos pueden ser, por ejemplo, dispositivos portátiles, electrodomésticos, ordenadores portátiles, ordenadores de sobremesa, ordenadores centrales, sistemas informáticos distribuidos, centros de datos o incluso dispositivos que convencionalmente no han sido considerados sistemas informáticos, tales como ciertos dispositivos portátiles (por ejemplo, gafas). En esta descripción y en las reivindicaciones, el término "sistema informático" se define a grandes rasgos como incluyendo cualquier dispositivo o sistema (o una combinación de éstos) que incluye al menos un procesador físico y tangible, y una memoria física y tangible capaz de tener en ella instrucciones ejecutables por ordenador que pueden ser ejecutadas por un procesador. La memoria puede adoptar cualquier forma y puede depender de la naturaleza y forma del sistema informático. Un sistema informático puede distribuirse por un entorno de red y puede incluir múltiples sistemas informáticos constituyentes.
Como se ilustra en la figura 1, en su configuración más básica, un sistema informático 100 incluye típicamente al menos una unidad 102 de procesamiento de hardware y una memoria 104. La unidad 102 de procesamiento puede incluir un procesador de fines generales, y puede incluir también una matriz de puertas programable en campo (FPGA), un circuito integrado de aplicación específica (ASIC) o cualquier otro circuito especializado. La memoria 104 puede ser una memoria física de sistema, que puede ser volátil, no volátil o alguna combinación de ambas. El término "memoria" puede también usarse en el presente documento para referirse a almacenamiento masivo no volátil, tal como medios de almacenamiento físico. Si el sistema informático está distribuido, la capacidad de procesamiento, de memoria y/o de almacenamiento puede también estar distribuida.
El sistema informático 100 tiene también múltiples estructuras a las que a menudo se hace referencia como "componente ejecutable". Por ejemplo, la memoria 104 del sistema informático 100 se ilustra como incluyendo el componente ejecutable 106. El término "componente ejecutable" es el nombre de una estructura que entiende bien el experto en la técnica en el campo de la informática como una estructura que puede ser software, hardware o una combinación de ambos. Por ejemplo, cuando se implante en software, el experto en la técnica entenderá que la estructura de un componente ejecutable puede incluir objetos, rutinas, métodos, etc. de software, que pueden ejecutarse en el sistema informático, ya sea que exista tal componente ejecutable en el conglomerado de un sistema informático, o que el componente ejecutable exista en un medio de almacenamiento legible por ordenador.
En tal caso, el experto en la técnica reconocerá que la estructura del componente ejecutable existe en un medio legible por ordenador de tal manera que, cuando sea interpretada por uno o más procesadores de un sistema informático (por ejemplo, por un subproceso del procesador), el sistema informático será impelido a realizar una función. Tal estructura puede ser legible por ordenador directamente por los procesadores (como en el caso de que el componente ejecutable sea binario). Alternativamente, la estructura puede estructurarse para que sea interpretable y/o compilada (ya sea en una sola etapa o en múltiples etapas) como para generar que tal binario sea directamente interpretable por los procesadores. Tal comprensión de estructuras de ejemplo de un componente ejecutable está justamente dentro de la comprensión del experto en la técnica de la informática cuando se usa el término "componente ejecutable".
El experto en la técnica entiende también bien que el término "componente ejecutable" incluye estructuras, tales como puertas lógicas codificadas o cableadas, que se implantan exclusiva o casi exclusivamente en hardware, tal como dentro de una matriz de puertas programable en campo (FPGA), un circuito integrado de aplicación específica (ASIC) o cualquier otro circuito especializado. Por consiguiente, el término "componente ejecutable" es un término para una estructura que entiende bien el experto en la técnica de la informática, ya sea implantada en software, hardware o en una combinación de éstos. En esta descripción, se pueden también utilizar los términos "componente", "agente", "gestor", "servicio", "motor", "módulo", "máquina virtual" o similares. Como se utilizan en esta descripción y en el caso, estos términos (ya sea expresados con o sin una cláusula modificadora) pretenden también ser sinónimos del término "componente ejecutable", y, de este modo, tienen también una estructura que es bien entendida por aquellos que poseen el saber hacer habitual en el arte de la informática.
En la descripción que sigue, se describen realizaciones con referencia a actos que son realizados por uno o más sistemas informáticos. Si tales actos se implantan en software, uno o más procesadores (del sistema informático asociado que realiza el acto) dirigen el funcionamiento del sistema informático en respuesta a haber ejecutado instrucciones ejecutables por ordenador que constituyen un componente ejecutable. Por ejemplo, tales instrucciones ejecutables por ordenador pueden incorporarse en uno o más medios legibles por ordenador que forman un producto de programa informático. Un ejemplo de tal función implica la manipulación de datos. Si tales actos se implantan exclusiva o casi exclusivamente en hardware, tal como dentro de una FPGA o de un ASIC, las instrucciones ejecutables por ordenador pueden ser puertas lógicas codificadas o cableadas. Las instrucciones ejecutables por ordenador (y los datos manipulados) pueden almacenarse en la memoria 104 del sistema informático 100. El sistema informático 100 puede también contener canales 108 de comunicación que permiten que el sistema informático 100 se comunique con otros sistemas informáticos a través de, por ejemplo, la red 110.
Si bien no todos los sistemas informáticos requieren una interfaz de usuario, en algunas realizaciones, el sistema informático 100 incluye un sistema 112 de interfaz de usuario para su usar en interacción con un usuario. El sistema 112 de interfaz de usuario puede incluir mecanismos 112A de salida así como mecanismos 112B de entrada. Los principios descritos en el presente documento no se limitan a los mecanismos 112A de salida precisos o a los mecanismos 112B de entrada, ya que, como tales, dependerán de la naturaleza del dispositivo. Sin embargo, los mecanismos 112A de salida podrían incluir, por ejemplo, altavoces, dispositivos de visualización, salida táctil, realidad virtual o aumentada, hologramas, etc. Los ejemplos de mecanismos 112B de entrada podrían incluir, por ejemplo, micrófonos, pantallas táctiles, realidad virtual o aumentada, hologramas, cámaras, teclados, un ratón u otra entrada de puntero, sensores de cualquier tipo, etc.
Las realizaciones descritas en el presente documento pueden comprender o utilizar un sistema informático de fines especiales o generales que incluye hardware informático, tal como, por ejemplo, uno o más procesadores y memoria de sistema, como se analiza con mayor detalle más adelante. Las realizaciones descritas en el presente documento incluyen también medios físicos y otros medios legibles por ordenador para transportar o almacenar instrucciones y/o estructuras de datos ejecutables por ordenador. Tales medios legibles por ordenador pueden ser cualquier medio disponible al que pueda acceder un sistema informático de fines generales o de fines especiales. Los medios legibles por ordenador que almacenan instrucciones ejecutables por ordenador son medios de almacenamiento físico. Los medios legibles por ordenador que llevan instrucciones ejecutables por ordenador son medios de transmisión. De este modo, a modo de ejemplo, y sin limitación, las realizaciones de la invención pueden comprender al menos dos clases claramente diferentes de medios legibles por ordenador: medios de almacenamiento y medios de transmisión.
Los medios de almacenamiento legibles por ordenador incluyen RAM, ROM, EEPROM, CD-ROM u otro almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio de almacenamiento físico y tangible que pueda usarse para almacenar medios de código de programa deseados en forma de estructuras de datos o de instrucciones ejecutables por ordenador y a los que se puede acceder mediante un sistema informático de fines generales o especiales.
Una "red" se define como uno o más enlaces de datos que permiten el transporte de datos electrónicos entre sistemas informáticos y/o módulos y/u otros dispositivos electrónicos. Cuando la información se transfiere o proporciona a través de una red u otra conexión de comunicaciones (ya sea cableada, inalámbrica o una combinación de cableada o inalámbrica) a un sistema informático, el sistema informático ve de manera apropiada la conexión como un medio de transmisión. Los medios de transmisión pueden incluir una red y/o enlaces de datos que pueden usarse para llevar medios de código de programa deseados en forma de estructuras de datos o de instrucciones ejecutables por ordenador y a los que se puede acceder mediante un sistema informático de fines generales o especiales. Las combinaciones de lo anterior también deben incluirse dentro del alcance de los medios legibles por ordenador.
Además, al alcanzar diversos componentes del sistema informático, los medios de código de programa en forma de instrucciones ejecutables por ordenador o de estructuras de datos se pueden transferir automáticamente desde los medios de transmisión a los medios de almacenamiento (o viceversa). Por ejemplo, las instrucciones ejecutables por ordenador o las estructuras de datos recibidas a través de una red o de un enlace de datos pueden almacenarse en memoria intermedia en RAM dentro de un módulo de interfaz de red (por ejemplo, una "NIC"), y, luego, al final, transferirse a la RAM de sistema informático y/o a medios de almacenamiento menos volátiles en un sistema informático. De este modo, debe entenderse que los medios de almacenamiento pueden incluirse en componentes de sistema informático que también (o incluso principalmente) utilizan medios de transmisión.
Las instrucciones ejecutables por ordenador comprenden, por ejemplo, instrucciones y datos que, cuando se ejecutan en un procesador, hacen que un sistema informático de fines generales, un sistema informático de fines especiales o un dispositivo de procesamiento de fines especiales realice una cierta función o un cierto grupo de funciones. Alternativamente, o además, las instrucciones ejecutables por ordenador pueden configurar el sistema informático para realizar una cierta función o un cierto grupo de funciones. Las instrucciones ejecutables por ordenador pueden ser, por ejemplo, binarias, o incluso instrucciones de las que se someten a alguna traducción (tal como una compilación) antes de la ejecución directa por parte de los procesadores, tal como instrucciones de formato intermedio tal como lenguaje de montaje, o incluso código fuente.
Aunque el objeto se ha descrito en un lenguaje específico de características estructurales y/o de actos metodológicos, debe entenderse que el objeto definido en las reivindicaciones adjuntas no se limita necesariamente a las características descritas o a los actos descritos anteriormente. Más bien, las características y actos descritos se divulgan como formas de ejemplo de implantación de las reivindicaciones.
El experto en la técnica apreciará que la invención se puede poner en práctica en entornos informáticos en red con muchos tipos de configuraciones de sistemas informáticos, incluyendo ordenadores personales, ordenadores de sobremesa, ordenadores portátiles, procesadores de mensajes, dispositivos de mano, sistemas multiprocesador, electrónica de consumo programable o basada en microprocesadores, PC de red, miniordenadores, ordenadores centrales, teléfonos móviles, PDA, radiolocalizadores, enrutadores, conmutadores, centros de datos, dispositivos de llevar puestos (tales como gafas) y similares. La invención se puede también practicar en entornos de sistemas distribuidos en los que realizan tareas sistemas informáticos tanto locales como remotos, estando tales sistemas vinculados a través de una red (ya sea mediante enlaces de datos cableados, enlaces de datos inalámbricos o mediante una combinación de enlaces de datos cableados e inalámbricos). En un entorno de sistema distribuido, los módulos de programa pueden ubicarse en dispositivos de almacenamiento de memoria tanto locales como remotos. El experto en la técnica apreciará también que la invención se puede poner en práctica en un entorno informático en la nube. Los entornos informáticos en la nube pueden distribuirse, aunque no es imprescindible. Cuando se distribuyen, los entornos informáticos en la nube pueden distribuirse internacionalmente dentro de una organización y/o tener componentes en propiedad en varias organizaciones. En esta descripción y las siguientes reivindicaciones, la "informática en la nube" se define como un modelo para permitir el acceso a la red bajo demanda a un conjunto compartido de recursos informáticos configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios). La definición de "informática en la nube" no se limita a ninguna de las numerosas ventajas que se pueden obtener de tal modelo cuando está de manera apropiada implantado.
Con las figuras restantes se analizan diversos sistemas informáticos que podrían corresponderse con el sistema informático 100 descrito anteriormente. Los sistemas informáticos de las figuras restantes incluyen diversos componentes o bloques funcionales que pueden implantar las diversas realizaciones divulgadas en el presente documento, según se explicará. Los diversos componentes o bloques funcionales pueden implantarse en un sistema informático local o pueden implantarse en un sistema informático distribuido que incluye elementos residentes en la nube o que implantan aspectos de informática en la nube. Los diversos componentes o bloques funcionales pueden implantarse como software, hardware o una combinación de software y hardware. Los sistemas informáticos de las figuras restantes pueden incluir más o menos componentes que aquéllos ilustrados en las figuras, y algunos de los componentes pueden combinarse según lo justifiquen las circunstancias.
Ahora se expondrá un análisis introductorio sobre un identificador descentralizado (DID) y el entorno en el que se crean y residen con respecto a la figura 2, que ilustra porciones de una red descentralizada 200. Como se ilustra en la figura 2, un propietario 201 de DID puede poseer o controlar un DID 205 que representa la identidad del propietario 201 de DID. El propietario 201 de DID puede registrar un DID utilizando un servicio de creación y registro, que se explicará con más detalle más adelante.
El propietario 201 de DID puede ser cualquier entidad que pudiera beneficiarse de un DID. Por ejemplo, el propietario 201 de DID puede ser un ser humano o una organización de seres humanos. Tales organizaciones pueden incluir una empresa, un departamento, un gobierno, una agencia o cualquier otra organización o grupo de organizaciones. Cada ser humano individual puede tener un DID, mientras que la organización o las organizaciones a las que pertenece cada uno podrían, de igual modo, tener un DID.
El propietario 201 de DID puede ser alternativamente una máquina, un sistema o un dispositivo, o un conjunto de máquinas, dispositivos y/o sistemas. En otras realizaciones más, el propietario 201 de DID puede ser una subparte de una máquina, de un sistema o de un dispositivo. Por ejemplo, un dispositivo podría ser una placa de circuito impreso, en el que las subpartes de esa placa de circuito son componentes individuales de la placa de circuito. En tales realizaciones, la máquina o dispositivo puede tener un DID, y cada subparte puede tener también un DID. Un propietario de DID podría también ser un componente de software tal como el componente ejecutable 106 descrito anteriormente con respecto a la figura 1. Un ejemplo de un componente ejecutable complejo 106 podría ser una inteligencia artificial. En consecuencia, una inteligencia artificial puede poseer también un d Id .
De este modo, el propietario 201 de DID puede ser cualquier entidad, humana o no humana, que sea capaz de crear el DID 205 o al menos tener el DID 205 creado para y/o asociado con ella. Aunque se muestra que el propietario 201 de DID tiene un único DID 205, este no tiene por qué ser el caso, ya que puede haber cualquier número de DID asociado con el propietario 201 de DID según lo justifiquen las circunstancias.
Como se mencionó, el propietario 201 de DID puede crear y registrar el DID 205. El DID 205 puede ser cualquier identificador que pueda estar asociado con el propietario 201 de DID. Preferiblemente, ese identificador es único para ese propietario 201 de DID, al menos dentro del ámbito en el que se prevé que se utilizará el DID. Como ejemplo, el identificador puede ser un identificador único localmente, y, quizás más deseablemente, un identificador único global para sistemas de identidad que se prevé que funcionen globalmente. En algunas realizaciones, el DID 205 puede ser un identificador de recursos uniforme (URI) (tal como un localizador de recursos uniforme (URL)) u otro puntero que relaciona al propietario 201 de DID con mecanismos para aplicar en interacciones confiables con el propietario 201 de DID.
El DID 205 está "descentralizado" porque no requiere un sistema de gestión centralizado de terceros para su generación, gestión o uso. En consecuencia, el DID 205 permanece bajo el control del propietario 201 de DID. Esto es diferente de los ID centralizados convencionales que basan la confianza en autoridades centralizadas y que permanecen bajo el control de servicios de directorio corporativos, autoridades de certificación, registros de nombres de dominio, u otras autoridades centralizadas (denominados colectivamente "autoridades centralizadas" en el presente documento). Por consiguiente, el DID 205 puede ser cualquier identificador que esté bajo el control del propietario 201 de DID y que sea independiente de cualquier autoridad centralizada.
En algunas realizaciones, la estructura del DID 205 puede ser tan simple como un nombre de usuario o algún otro término comprensible para el ser humano. Sin embargo, en otras realizaciones, para mayor seguridad, el DID 205 puede ser preferiblemente una cadena aleatoria de números y letras. En una realización, el DID 205 puede ser una cadena de 128 números y letras. En consecuencia, las realizaciones divulgadas en el presente documento no dependen de ninguna implantación específica del DID 205. En un ejemplo muy simple, el DID 205 se muestra dentro de las figuras como "123ABC".
Como se muestra también en la figura 2, el propietario 201 de DID tiene control de un par de clave privada 206 y clave pública 207 que está asociada con el DID 205. Debido a que el DID 205 es independiente de cualquier autoridad centralizada, la clave privada 206 debe estar en todo momento en pleno control del propietario 201 de DID. Es decir, que las claves pública y privada deben generarse de una manera descentralizada que garantice que permanecen bajo el control del propietario 201 de DID.
Como se describirá con más detalle a continuación, el par de clave privada 206 y clave pública 207 se puede generar en un dispositivo controlado por el propietario 201 de DID. El par de clave privada 206 y clave pública 207 no se debe generar en un servidor controlado por cualquier autoridad centralizada, ya que esto puede hacer que el par de clave privada 206 y clave pública 207 no esté completamente bajo el control del propietario 201 de DID en todo momento. Aunque la figura 2 y esta descripción han descrito un par de claves pública y privada, se observará también que se pueden también usar otros tipos de información y/o de mecanismos criptográficos razonables según lo justifiquen las circunstancias.
La figura 2 también ilustra un documento 210 de DID que está asociado con el DID 205. Como se explicará con más detalle a continuación, el documento 210 de DID puede generarse en el momento en que se crea el DID 205. En su forma más simple, el documento 210 de DID describe cómo usar el DID 205. En consecuencia, el documento 210 de DID incluye una referencia al DID 205, que es el DID que se describe en el documento 210 de DID. En algunas realizaciones, el documento 210 de DID puede implantarse de acuerdo con métodos especificados por un libro de asientos distribuido 220 (tal como una cadena de bloques) que se usará para almacenar una representación del DID 205 como se explicará con más detalle a continuación. De este modo, el documento 210 de DID puede tener diferentes métodos dependiendo del libro de asientos distribuido específico.
El documento 210 de DID incluye también la clave pública 207 creada por el propietario 201 de DID, o alguna otra información criptográfica equivalente. La clave pública 207 puede ser utilizada por entidades de terceros a las que el propietario 201 de DID les otorga permiso para acceder a información y a datos propiedad del propietario 201 de DID. La clave pública 207 puede también usarse para verificar que el propietario 201 de DID posee o controla de hecho el DID 205.
El documento 210 de DID también puede incluir información 211 de autenticación. La información 211 de autenticación puede especificar uno o más mecanismos mediante los cuales el propietario 201 de DID puede probar que el propietario 201 de DID posee el DID 205. En otras palabras, los mecanismos de la información 211 de autenticación pueden mostrar la prueba de que existe una vinculación entre el DID 205 (y, de este modo, de su propietario 201 de DID) y el documento 210 de DID. En una realización, la información 211 de autenticación puede especificar que la clave pública 207 se use en una función para demostrar la propiedad del DID 205. Alternativamente, o además, la información 211 de autenticación puede especificar que la clave pública 207 se use en una función biométrica para demostrar la propiedad del DID 205. En consecuencia, la información 211 de autenticación puede incluir cualquier número de mecanismos mediante los cuales el propietario 201 de DID puede demostrar que el propietario 201 de DID posee el DID 205.
El documento 210 de DID puede también incluir información 212 de autorización. La información 212 de autorización puede permitir que el propietario 201 de DID autorice a entidades de terceros los derechos para modificar el documento 210 de DID o alguna parte del documento sin darle al tercero el derecho a demostrar la propiedad del DID 205. Por ejemplo, la información 212 de autorización puede permitir al tercero actualizar cualquier conjunto designado de uno o más campos en el documento 210 de DID usando cualquier mecanismo de actualización designado. Alternativamente, la información de autorización puede permitir al tercero limitar los usos del DID 205 por parte del propietario 201 de DID durante un período de tiempo especificado. Esto puede resultar útil cuando el propietario 201 de DID es un menor de edad y el tercero es el padre o tutor del niño. La información 212 de autorización puede permitir al padre o tutor limitar el uso del propietario 201 de DID hasta tal momento en el que el niño ya no sea menor de edad.
La información 212 de autorización puede también especificar uno o más mecanismos que el tercero necesitará seguir para demostrar que está autorizado a modificar el documento 210 de DID. En algunas realizaciones, estos mecanismos pueden ser similares a los analizados anteriormente con respecto a la información 211 de autenticación.
El documento 210 de DID también puede incluir uno o más puntos finales 213 de servicio. Un punto final de servicio puede incluir una dirección de red en la que un servicio funciona en nombre del propietario 201 de DID. Ejemplos de servicios específicos incluyen servicios de descubrimiento, redes sociales, servicios de almacenamiento de archivos, tal como servidores o concentradores de identidad, y servicios de depósito de reclamaciones verificables. En consecuencia, los puntos finales 213 de servicio funcionan como punteros para los servicios que funcionan en nombre del propietario 201 de DID. Estos punteros pueden ser utilizados por el propietario 201 de DID o por entidades de terceros para acceder a los servicios que funcionan en nombre del propietario 201 de DID. A continuación se explicarán con más detalle ejemplos específicos de puntos finales 213 de servicio.
El documento 210 de DID puede incluir adicionalmente información 214 de identificación. La información 214 de identificación puede incluir información de identificación personal tal como nombre, dirección, ocupación, miembros de la familia, edad, pasatiempos, intereses o similares del propietario 201 de DID. En consecuencia, la información 214 de identificación enumerada en el documento 210 de DID puede representar una persona diferente del propietario 201 de DID para diferentes fines.
La persona puede ser pseudoanónima. Como ejemplo, el propietario 201 de DID puede incluir un pseudónimo en el documento de DID al identificarlo como escritor que publica artículos en un blog. La persona puede ser completamente anónima. Por ejemplo, es posible que el propietario 201 de DID sólo desee revelar su puesto de trabajo u otros datos de sus antecedentes (por ejemplo, un maestro de escuela, un agente del FBI, un adulto mayor de 21 años, etc.), pero no su nombre en el documento de DID. Como otro ejemplo más, la persona puede ser específica de quién es el propietario 201 de DID como individuo. Como ejemplo, el propietario 201 de DID puede incluir información que lo identifique como voluntario de una organización benéfica en particular, como empleado de una corporación en particular, como ganador de un premio en particular, etc.
El documento 210 de DID puede incluir también información 215 de certificación. La información 215 de certificación puede ser cualquier información que esté asociada con los antecedentes del propietario 201 de DID. Por ejemplo, la información 215 de certificación puede ser (pero no limitarse a) una calificación, un logro, una identificación gubernamental, un derecho gubernamental tal como un pasaporte o un permiso de conducción, un proveedor de pagos o una cuenta bancaria, un título universitario u otro historial educativo, situación e historial laborales, o cualquier otra información sobre los antecedentes del propietario 201 de DID. En algunas realizaciones, el propietario 201 de DID recopila diversas certificaciones firmadas que se incluyen en la información de certificación de diferentes entidades de terceros.
El documento 210 de DID puede también incluir otra información 216. En algunas realizaciones, la otra información 216 puede incluir metadatos que especifican cuándo se creó el documento 210 de DID y/o cuándo se modificó por última vez. En otras realizaciones, la otra información 216 puede incluir pruebas criptográficas de la integridad del documento 210 de DID. En otras realizaciones más, la otra información 216 puede incluir información adicional que esté especificada por el método específico que implanta el documento de DID o deseada por el propietario 201 de DID.
La figura 2 ilustra también un libro de asientos distribuido 220. El libro de asientos distribuido 220 puede ser cualquier red distribuida descentralizada que incluya diversos sistemas informáticos que estén en comunicación entre sí. Por ejemplo, el libro de asientos distribuido 220 puede incluir un primer sistema informático distribuido 230, un segundo sistema informático distribuido 240, un tercer sistema informático distribuido 250 y cualquier número de sistemas informáticos distribuidos adicionales como se ilustra mediante los puntos suspensivos 260. El libro de asientos distribuido 220 puede funcionar de acuerdo con cualquier estándar o método conocido para libros de asientos distribuidos. Ejemplos de libros de asientos distribuidos convencionales que pueden corresponder al libro de asientos distribuido 220 incluyen, entre otros, Bitcoin [BTC], Ethereum y Litecoin.
En el contexto del DID 205, el libro de asientos distribuido o cadena de bloques 220 se usa para almacenar una representación del DID 205 que indica el documento 210 de DID. En algunas realizaciones, el documento 210 de DID puede almacenarse en el libro de asientos distribuido real. Alternativamente, en otras realizaciones, el documento 210 de DID puede almacenarse en un almacenamiento de datos (no ilustrado) que está asociado con el libro de asientos distribuido 220.
Como se mencionó, se almacena una representación del DID 205 en cada sistema informático distribuido del libro de asientos distribuido 220. Por ejemplo, en la figura 2 esto se muestra como una secuencia de números y caracteres generada al utilizar un algoritmo concreto (hash) 231 de DID, un hash 241 de DID y un hash 251 de DID, que son idealmente copias hash idénticas del mismo DID. El hash 231 de DID, el hash 241 de DID y el hash 251 de DID pueden indicar entonces la ubicación del documento 210 de DID. El libro de asientos distribuido o cadena de bloques 220 puede también almacenar otras numerosas representaciones de otros DID, como se ilustra mediante las referencias 232, 233, 234, 242, 243, 244, 252, 253 y 254.
En una realización, cuando el propietario 201 de DID crea el DID 205 y el documento 210 de DID asociado, el hash 231 de DID, el hash 241 de DID y el hash 251 de DID se escriben en el libro de asientos distribuido 220. El libro de asientos distribuido 220 graba, de este modo, que el DID 205 ya existe. Dado que el libro de asientos distribuido 220 está descentralizado, el DID 205 no está bajo el control de ninguna entidad fuera del propietario 201 de DID. El hash 231 de DID, el hash 241 de DID y el hash 251 de DID pueden incluir cada uno, además del puntero al documento 210 de DID, una grabación o un sello de tiempo, que especifica cuándo se creó el DID 205. En una fecha posterior, cuando se realizan modificaciones al documento 210 de DID, cada modificación (y potencialmente también una marca de tiempo de la modificación) puede también grabarse en el hash 231 de DID, el hash 241 de DID y el hash 251 de DID. El hash 231 de DID, el hash 241 de DID y el hash 251 de DID pueden incluir adicionalmente una copia de la clave pública 207 de modo que el DID 205 esté vinculado criptográficamente al documento 210 de DID.
Habiendo descrito los DID y cómo funcionan en general con referencia a la figura 2, se explicarán ahora realizaciones específicas de entornos de DID. Volviendo a la figura 3, se explicará ahora un entorno 300 de sistema informático que puede usarse para realizar diversas funciones y servicios de gestión de DID. Se apreciará que el entorno de la figura 3 puede hacer referencia a elementos de la figura 2 según sea necesario para facilitar la explicación.
Como se muestra en la figura 3, el entorno 300 puede incluir diversos dispositivos y sistemas informáticos que pueden ser propiedad o, si no, estar bajo el control del propietario 201 de DID. Estos pueden incluir un dispositivo 301 de usuario. El dispositivo 301 de usuario puede ser, pero sin limitarse a, un dispositivo móvil tal como un teléfono inteligente, un dispositivo informático tal como un ordenador portátil, o cualquier dispositivo tal como un automóvil o un electrodoméstico que incluya capacidades informáticas. El dispositivo 301 puede incluir un navegador web 302 que funcione en el dispositivo y un sistema operativo 303 que haga funcionar el dispositivo. En términos más a grandes rasgos, la línea discontinua 304 representa que todos estos dispositivos pueden ser propiedad o estar bajo el control del propietario 201 de DID.
El entorno 300 incluye también un módulo 320 de gestión de DID. Se observará que, en funcionamiento, el módulo 320 de gestión de DID puede residir y ser ejecutado por uno o más elementos de entre el dispositivo 301 de usuario, el navegador web 302 y el sistema operativo 303 como se ilustra por las respectivas líneas 301a, 302a y 303a. En consecuencia, el módulo 320 de gestión de DID se muestra separado para facilitar la explicación. En algunas realizaciones, el módulo 320 de gestión puede denominarse "cartera digital" o "agente de usuario".
Como se muestra en la figura 3, el módulo 320 de gestión de DID incluye un módulo 330 de creación de DID. El módulo 330 de creación de DID puede ser utilizado por el propietario 201 de DID para crear el DID 205 o cualquier número de DID adicionales, tales como el DID 331. En una realización, el módulo de creación de DID puede incluir o tener acceso de otro modo a un elemento 335 de interfaz de usuario (UI) que puede guiar al propietario 201 de DID en la creación del DID 205. El módulo 330 de creación de DID puede tener uno o más controladores que son configurados para trabajar con libros de asientos distribuidos específicos tales como el libro de asientos distribuido 220 de modo que el DID 205 cumpla con los métodos fundamentales de ese libro de asientos distribuido.
A continuación se describirá una realización específica. Por ejemplo, la UI 335 puede proporcionar un mensaje para que el usuario introduzca un nombre de usuario o algún otro nombre reconocible por un ser humano. Este nombre se puede utilizar como nombre de exhibición visual para el DID 205 que se generará. Como se describió anteriormente, el DID 205 puede ser una larga cadena de números y letras aleatorios, y, por lo tanto, puede ser ventajoso tener un nombre reconocible por un ser humano como nombre para exhibir visualmente. El módulo 330 de creación de DID puede generar entonces el DID 205. En las realizaciones que tienen la UI 335, el DID 205 puede mostrarse en una lista de identidades y puede asociarse con el nombre reconocible por un ser humano.
El módulo 330 de creación de DID también puede incluir un módulo 350 de generación de claves. El módulo de generación de claves puede generar el par de clave privada 206 y clave pública 207 descrito anteriormente. El módulo 330 de creación de DID puede entonces usar el DID 205 y el par de claves pública y privada para generar el documento 210 de DID.
En funcionamiento, el módulo 330 de creación de DID accede a un registrador 310 que está configurado para el libro de asientos distribuido específico que grabará las transacciones relativas al DID 205. El módulo 330 de creación de DID utiliza el registrador 310 para grabar el hash 231 de DID, el hash 241 de DID y el hash 251 de DID en el libro de asientos distribuido de la manera descrita anteriormente, y para almacenar el documento 210 de DID de la manera descrita anteriormente. Este proceso puede utilizar la clave pública 207 en la generación del hash.
En algunas realizaciones, el módulo 320 de gestión de DID puede incluir un módulo 340 de propiedad. El módulo 340 de propiedad puede proporcionar mecanismos que aseguren que el propietario 201 de DID tiene el control exclusivo del DID 205. De esta manera, el proveedor del módulo 320 de gestión de DID puede garantizar que el proveedor no controle el DID 205 sino que sólo proporcione los servicios de gestión.
Como se analizó anteriormente, el módulo 350 de generación de claves genera el par de clave privada 206 y clave pública 207, y la clave pública 207 se graba luego en el documento 210 de DID. En consecuencia, la clave pública 207 puede ser utilizada por todos los dispositivos asociados con el propietario 201 de DID y por todos los terceros que deseen proporcionar servicios al propietario 201 de DID. En consecuencia, cuando el propietario 201 de DID desea asociar un nuevo dispositivo con el DID 205, el propietario 201 de DID puede ejecutar el módulo 330 de creación de DID en el nuevo dispositivo. El módulo 330 puede de creación de DID usar entonces el registrador 310 para actualizar el documento 210 de DID para reflejar que el nuevo dispositivo está ahora asociado con el DID 205, actualización la cual se reflejará en una transacción en el libro de asientos distribuido 220, como se describió anteriormente.
En algunas realizaciones, sin embargo, puede ser ventajoso tener una clave pública por dispositivo 301 propiedad del propietario 201 de DID ya que esto puede permitir que el propietario 201 de DID firme con la clave pública específica del dispositivo sin tener que acceder a una clave pública general. En otras palabras, dado que el propietario 201 de DID usará diferentes dispositivos en diferentes momentos (por ejemplo, usando un teléfono móvil en un caso y luego usando un ordenador portátil en otro caso), es ventajoso tener una clave asociada con cada dispositivo para proporcionar eficiencia en la firma utilizando las claves. En consecuencia, en tales realizaciones, el módulo 350 de generación de claves puede generar claves públicas adicionales 208 y 209 cuando los dispositivos adicionales ejecuten el módulo 330 de creación de DID. Estas claves públicas adicionales pueden estar asociadas con la clave privada 206, o, en algunos casos, pueden estar emparejadas con una nueva clave privada.
En aquellas realizaciones en las que las claves públicas adicionales 208 y 209 están asociadas con diferentes dispositivos, las claves públicas adicionales 208 y 209 pueden grabarse en el documento 210 de DID como asociadas con esos dispositivos. Esto se muestra en la figura 3. Se apreciará que el documento 210 de DID puede incluir la información (información 205, 207 y 211 a 216) descrita previamente en relación con la figura 2, además de la información (información 208, 209 y 365) que se muestra en la figura 3. Si el documento 210 de DID existía antes de que se generaran las claves públicas específicas del dispositivo, entonces el documento 210 de DID sería actualizado por el módulo 330 de creación mediante el registrador 310, y esto se reflejaría en una transacción actualizada en el libro de asientos distribuido 220.
En algunas realizaciones, el propietario 201 de DID puede desear mantener en secreto la asociación de un dispositivo con una clave pública o la asociación de un dispositivo con el DID 205. En consecuencia, el módulo 330 de creación de DID puede provocar que tales datos se muestren en el documento 210 de DID.
Como se ha descrito hasta ahora, el DID 205 se ha asociado con todos los dispositivos bajo el control del propietario 201 de DID, incluso cuando los dispositivos tienen sus propias claves públicas. Sin embargo, en algunas realizaciones puede ser útil que cada dispositivo o algún subconjunto de dispositivos bajo el control del propietario 201 de DID tenga cada uno su propio DID. De este modo, en algunas realizaciones, el módulo 330 de creación de DID puede generar un DID adicional, por ejemplo el DID 331, para cada dispositivo. El módulo 330 de creación de DID generaría entonces pares de claves públicas y privadas y documentos DID para cada uno de los dispositivos, y los grabaría en el libro de asientos distribuido 220 de la manera descrita anteriormente. Tales realizaciones pueden ser ventajosas para dispositivos que pueden cambiar de propietario, ya que puede ser posible asociar el DID específico del dispositivo al nuevo propietario del dispositivo otorgando derechos de autorización al nuevo propietario en el documento de DID y revocando tales derechos del antiguo propietario.
Como se mencionó, para garantizar que la clave privada 206 esté totalmente bajo el control del propietario 201 de DID, la clave privada 206 se crea en el dispositivo 301 de usuario, en el navegador 302 o en el sistema operativo 303 que es propiedad o está controlado por el propietario 201 de DID que ejecutó el módulo 320 de gestión de DID. De esta manera, hay pocas posibilidades de que un tercero (y, más en consecuencia, el proveedor 320 del módulo de gestión de DID) pueda obtener el control de la clave privada 206.
Sin embargo, existe la posibilidad de que el propietario 201 de DID pierda el dispositivo que almacena la clave privada 206, lo que puede ocasionar que el propietario 201 de DID pierda el acceso al DID 205. En consecuencia, en algunas realizaciones, la UI 335 puede incluir una opción que permita que el propietario 201 de DID exporte la clave privada 206 a una base de datos segura fuera del dispositivo 305 que está bajo el control del propietario 201 de DID. Como ejemplo, la base 305 de datos puede ser uno de los concentradores 410 de identidad descritos más adelante con respecto a la figura 4. Un módulo 380 de almacenamiento está configurado para almacenar datos (tales como la clave privada 206 o la información 215 de certificación realizada por o sobre el propietario 201 de DID) fuera del dispositivo en la base 305 de datos o en los concentradores 410 de identidad que se describirán con más detalle a continuación. Por supuesto, en algunas realizaciones, el módulo 380 de almacenamiento puede almacenar al menos algunos datos en el dispositivo si el dispositivo tiene suficientes recursos de almacenamiento. En algunas realizaciones, la clave privada 206 puede almacenarse como un código QR que puede ser escaneado por el propietario 201 de DID.
En otras realizaciones, el módulo 320 de gestión de DID puede incluir un módulo 360 de recuperación que puede usarse para recuperar una clave privada perdida 206. En funcionamiento, el módulo 360 de recuperación permite que el propietario 201 de DID seleccione uno o más mecanismos 365 de recuperación en el momento en que se crea el DID 205 que luego podrá usarse para recuperar la clave privada perdida. En aquellas realizaciones que tienen la UI 335, la UI 335 puede permitir que el propietario 201 de DID proporcione información que será utilizada por el uno o más mecanismos 365 de recuperación durante la recuperación. El módulo 360 de recuperación puede entonces ejecutarse en cualquier dispositivo asociado con el DID 205.
El módulo 320 de gestión de DID puede también incluir un módulo 370 de revocación que se usa para revocar o separar un dispositivo 205 del DID. En funcionamiento, el módulo de revocación puede usar el elemento 335 de UI, que puede permitir que el propietario 201 de DID indique su deseo de eliminar un dispositivo para que no esté asociado con el DID 205. En una realización, el módulo 370 de revocación puede acceder al documento 210 de DID y puede hacer que todas las referencias al dispositivo se eliminen del documento 210 de DID. Alternativamente, se puede retirar la clave pública del dispositivo. Este cambio en el documento 210 de DID puede reflejarse luego como una transacción actualizada en el libro de asientos distribuido 220 como se describió anteriormente.
La figura 4 ilustra una realización de un entorno 400 de sistema informático en el que se puede utilizar un DID tal como el DID 205. Específicamente, el entorno 400 se va a usar para describir el uso del DID 205 en relación con uno o más almacenamientos descentralizados o concentradores 410 de identidad que están cada uno bajo el control del propietario 201 de DID para almacenar datos que pertenecen o se refieren al propietario 201 de DID. Por ejemplo, los datos pueden almacenarse dentro de los concentradores de identidad usando el módulo 380 de almacenamiento de la figura 3. Se observará que la figura 4 puede incluir referencias a elementos discutidos primero en relación con las figuras 2 ó 3, y, de este modo, se usa el mismo número de referencia para facilitar la explicación.
En una realización, los concentradores 410 de identidad pueden ser múltiples casos del mismo concentrador de identidad. Esto está representado por la línea 410A. De este modo, los diversos concentradores 410 de identidad pueden incluir al menos algunos de los mismos datos y servicios. En consecuencia, si se realiza un cambio en parte de al menos algunos de los datos (y potencialmente cualquier parte de cualquiera de los datos) en uno de los concentradores 410 de identidad, el cambio puede reflejarse en uno o más de (y quizás en todos) los concentradores de identidad restantes.
Los concentradores 410 de identidad pueden ser cualquier almacenamiento de datos que pueda estar bajo el control exclusivo del propietario 201 de DID. Sólo como ejemplo, el primer concentrador 411 de identidad y el segundo concentrador 412 de identidad se implantan en almacenamiento en la nube (quizás dentro de la misma nube, o incluso en diferentes nubes gestionadas por diferentes proveedores de nube) y, de este modo, pueden contener una gran cantidad de datos. En consecuencia, se puede almacenar un conjunto completo de datos en estos concentradores de identidad.
Sin embargo, los concentradores 413 y 414 de identidad pueden tener menos espacio de memoria. En consecuencia, en estos concentradores de identidad se puede incluir un descriptor de los datos almacenados en los concentradores primero y segundo de identidad. Alternativamente, se puede incluir una grabación de los cambios realizados en los datos en otros concentradores de identidad. De este modo, los cambios en uno de los concentradores 410 de identidad se replican completamente en los otros concentradores de identidad, o al menos se graba una grabación o un descriptor de esos datos en los otros concentradores de identidad.
Debido a que los concentradores de identidad pueden ser múltiples casos del mismo concentrador de identidad, sólo se proporcionará una descripción completa del primer concentrador 411 de identidad, ya que esta descripción puede también aplicarse a los concentradores 412 a 414 de identidad. Como se ilustra, el concentrador 411 de identidad puede incluir almacenamiento 420 de datos. El almacenamiento 420 de datos puede usarse para almacenar cualquier tipo de datos que estén asociados con el propietario 201 de DID. En una realización, los datos pueden ser una recopilación 422 de un tipo específico de datos correspondiente a un protocolo específico. Por ejemplo, la recopilación 422 puede ser de datos de grabaciones médicas que corresponden a un protocolo específico para datos médicos. La recopilación 422 puede incluir cualquier otro tipo de datos, tales como certificaciones 215 hechas por o sobre el propietario 201 de DID.
En una realización, los datos almacenados pueden tener diferentes configuraciones 421 de autenticación y privacidad asociadas con los datos almacenados. Por ejemplo, un primer subconjunto de datos puede tener una configuración 421 que permite que los datos se expongan públicamente, pero que no incluye ninguna autenticación para el propietario 201 de DID. Este tipo de datos puede ser para datos relativamente sin importancia, tales como esquemas de color y similares. Un segundo subconjunto de los datos puede tener una configuración 421 que permite que los datos se expongan públicamente y que incluye autenticación ante el propietario 201 de DID. Un tercer subconjunto de los datos puede tener una configuración 421 que encripta el subconjunto de datos con el par de clave privada 206 y clave pública 207 (o algún otro par de claves) asociado con el propietario 201 de DID. Este tipo de datos requerirá que una parte tenga acceso a la clave pública 207 (o a alguna otra clave pública asociada) para poder desencriptar los datos. Este proceso puede también incluir autenticación para el propietario 201 de DID. Un cuarto subconjunto de datos puede tener una configuración 421 que restringe estos datos a un subconjunto de terceros. Esto puede requerir que se utilicen claves públicas asociadas con el subconjunto de terceros para desencriptar los datos. Por ejemplo, el propietario 201 de DID puede hacer que la configuración 421 especifique que sólo las claves públicas asociadas con amigos del propietario 201 de DID pueden desencriptar estos datos. Con respecto a los datos almacenados por el módulo 380 de almacenamiento, estas configuraciones 411 pueden estar compuestas, al menos parcialmente, por el módulo 380 de almacenamiento de la figura 3.
En algunas realizaciones, el concentrador 411 de identidad puede tener un módulo 430 de permisos que permite al propietario 201 de DID establecer autorización o permisos específicos para que terceros tales como terceros 401 y 402 accedan al concentrador de identidad. Por ejemplo, el propietario 201 de DID puede proporcionar permiso de acceso a su cónyuge a todos los datos 420. Alternativamente, el propietario 201 de DID puede permitir el acceso a su médico para cualquier grabación médica. Se apreciará que el propietario 201 de DID puede dar permiso a cualquier número de terceros para acceder a un subconjunto de los datos 420. Esto se explicará con más detalle a continuación. Con respecto a los datos almacenados por el módulo 380 de almacenamiento, estos permisos 430 de acceso pueden estar compuestos al menos parcialmente por el módulo 380 de almacenamiento de la figura 3. El concentrador 411 de identidad puede tener también un módulo 440 de mensajería. En funcionamiento, el módulo de mensajería permite que el concentrador de identidad reciba mensajes tales como solicitudes de partes tales como terceros 401 y 402 para acceder a los datos y servicios del concentrador de identidad. Además, el módulo 440 de mensajería permite que el concentrador 411 de identidad responda a los mensajes de terceros y se comunique también con un solucionador 450 de DID. Esto se explicará con más detalle a continuación. Los puntos suspensivos 416 representan que el concentrador 411 de identidad puede tener servicios adicionales según lo justifiquen las circunstancias.
En una realización, el propietario 201 de DID puede desear autenticar un nuevo dispositivo 301 con el concentrador 411 de identidad que ya está asociado con el DID 205 de la manera descrita anteriormente. En consecuencia, el propietario 201 de DID puede utilizar el módulo 320 de gestión de DID asociado con el nuevo dispositivo 301 de usuario para enviar un mensaje al concentrador 411 de identidad afirmando que el nuevo dispositivo de usuario está asociado con el DID 205 del propietario 201 de DID.
Sin embargo, es posible que el concentrador 411 de identidad no reconozca inicialmente el nuevo dispositivo como propiedad del propietario 201 de DID. En consecuencia, el concentrador 411 de identidad puede usar el módulo 440 de mensajería para ponerse en contacto con el solucionador 450 de DID. El mensaje enviado al solucionador 450 de DID puede incluir el DID 205.
El solucionador 450 de DID puede ser un servicio, una aplicación o un módulo que esté configurado en funcionamiento para buscar en el libro de asientos distribuido 220 documentos DID asociados con DID. En consecuencia, en la realización, el solucionador 450 de DID puede buscar en el libro de asientos distribuido 220 usando el DID 205, lo que puede dar como resultado que el solucionador 450 de DID encuentre el documento 210 de DID. El documento 210 de DID puede entonces proporcionarse al concentrador 411 de identidad.
Como se analizó anteriormente, el documento 210 de DID puede incluir una clave pública 208 o 209 que está asociada con el nuevo dispositivo 301 de usuario. Para verificar que el nuevo dispositivo de usuario es propiedad del propietario 201 de DID, el concentrador 411 de identidad puede proporcionar un desafío criptográfico al nuevo dispositivo 301 de usuario utilizando el módulo 440 de mensajería. Este desafío criptográfico se estructurará de tal manera que sólo un dispositivo que tenga acceso a la clave privada 206 podrá responder con éxito al desafío.
En esta realización, dado que el nuevo dispositivo de usuario es propiedad del propietario 201 de DID y de este modo tiene acceso a la clave privada 206, el desafío puede responderse con éxito. El concentrador 411 de identidad puede entonces grabar en los permisos 430 que el nuevo dispositivo 301 de usuario puede acceder a los datos y servicios del concentrador 411 de identidad y también al resto de los concentradores 410 de identidad.
Se observará que este proceso de autenticación del nuevo dispositivo 301 de usuario se realizó sin la necesidad de que el propietario 201 de DID proporcionara ningún nombre de usuario, contraseña o similar al proveedor del concentrador 411 de identidad (es decir, al primer proveedor de almacenamiento en la nube) antes de que se pudiera acceder al concentrador 411 de identidad. Más bien, el acceso se determinó de manera descentralizada en base al DID 205, al documento 210 de DID y a las claves públicas y privadas asociadas. Dado que estas estuvieron en todo momento bajo el control del propietario 201 de DID, el proveedor del concentrador 411 de identidad no estuvo involucrado, y, de este modo, no tiene conocimiento de la transacción ni de ninguna información personal del propietario 201 de DID.
En otra realización de ejemplo, el propietario 201 de DID puede proporcionar el DID 205 a la entidad 401 de terceros para que el tercero pueda acceder a datos o servicios almacenados en el concentrador 411 de identidad. Por ejemplo, el propietario 201 de DID puede ser un ser humano que está en una conferencia científica y que desea permitir que un tercero 401, que también es un ser humano, acceda a sus datos de investigación. En consecuencia, el propietario 201 de DID puede proporcionar el DID 205 al tercero 401.
Una vez que el tercero 401 tiene acceso al DID 205, puede acceder al solucionador 450 de DID para acceder al documento 210 de DID. Como se analizó anteriormente, el documento 210 de DID puede incluir un punto final 213 que es una dirección o puntero a servicios asociados con la identidad descentralizada.
Para completar el ejemplo de datos de investigación, el tercero 401 puede enviar un mensaje al módulo 440 de mensajería solicitando permiso para acceder a los datos de investigación. El módulo 440 de mensajería puede entonces enviar un mensaje al propietario 201 de DID preguntando si el tercero 401 debería tener acceso a los datos de la investigación. Debido a que el propietario de DID desea proporcionar acceso a estos datos, el propietario 201 de DID puede otorgar permiso al tercero 401, y este permiso puede grabarse en los permisos 430.
El módulo 440 de mensajería puede entonces enviar un mensaje al tercero 401 informándole de que puede acceder a los datos de la investigación. El concentrador 411 de identidad y el tercero 401 pueden entonces comunicarse directamente para que el tercero pueda acceder a los datos. Se observará que, en muchos casos, en realidad será un concentrador de identidad asociado con el tercero 401 el que se comunica con el concentrador 411 de identidad. Sin embargo, puede ser un dispositivo del tercero 401 el que realiza la comunicación.
Ventajosamente, el proceso descrito anteriormente permite que el concentrador 411 de identidad y el tercero 401 se comuniquen y compartan los datos sin la necesidad de que el tercero acceda al concentrador 411 de identidad de la manera convencional. Más bien, la comunicación se proporciona de manera descentralizada utilizando el DID 205 y el documento 210 de DID. Esto permite ventajosamente que el propietario de DID tenga control total del proceso.
Como se muestra en la figura 4, el tercero 402 puede también solicitar permiso para acceder al concentrador 411 de identidad usando el DID 205 y el documento 210 de DID. En consecuencia, las realizaciones divulgadas en el presente documento permiten el acceso a cualquier número de terceros a los concentradores 410 de identidad.
La figura 5A ilustra una realización de un entorno 500 de sistema informático que se va a utilizar para explicar cómo un propietario de DID puede controlar la delegación de datos relativos a DID de acuerdo con las realizaciones divulgadas en el presente documento. Se observará que, dado que el entorno del sistema informático 500 puede corresponder a uno o más de los entornos del sistema informático 100-400 descritos anteriormente, la figura 5A puede incluir referencias a elementos analizados primero en relación con las figuras 2-4, y que, de este modo, puede usar el mismo número de referencia para facilitar la explicación.
Supóngase que el propietario 201 de DID deseara delegar permiso a una entidad 530 de terceros, que puede poseer o estar asociada de otro modo con un DID 535, para acceder a uno o más objetos de datos relativos a DID, tales como objetos 420A y 420B de datos, que se incluyen en los datos 420 almacenados en el concentrador 411 de identidad. Los objetos 420A y 420B de datos relativos a DID pueden considerarse "relativos a DID" ya que los datos son identificados por y asociados con el DID 205 del propietario 201 de DID. Los objetos 420A y 420B de datos relativos a DID pueden incluir cualquier tipo razonable de datos, tal como video, audio, imagen, datos de documentos. Por consiguiente, la realización descrita en el presente documento no está limitada por el tipo de objetos 420A y 420B de datos relativos a DID.
A la entidad 530 de terceros se le puede dar acceso a uno o más de los objetos 420A y 420B de datos relativos a DID para que la entidad 530 de terceros pueda leer y/o escribir o hacer funcionar o utilizar de otro modo los objetos de datos. Por ejemplo, el objeto 420A de datos relativos a DID puede ser un vídeo del propietario 201 de DID que será visto por la entidad 530 de terceros o puede ser un documento que será editado por la entidad 530 de terceros. Dado que el propietario 201 de DID desea delegar permiso para acceder a los objetos de datos relativos a DID a la entidad 530 de terceros, no hay ningún problema cuando la entidad 530 de terceros lee o escribe en los objetos de datos. En algunas realizaciones, los objetos 420A y/o 420B de datos relativos a DID pueden ser encriptados por el propietario 201 de DID usando el par 206 y 207 de claves pública y privada como se describió anteriormente. En tal caso, a la entidad 530 de terceros se le puede proporcionar acceso a la clave pública 207 para que el objeto encriptado de datos relativos a DID pueda desencriptarse.
Aunque el propietario 201 de DID puede desear delegar permiso para usar los objetos de datos relativos a DID a la entidad 530 de terceros, puede no desear que la entidad 530 de terceros delegue adicionalmente permiso para usar los objetos de datos relativos a DID con otras entidades de terceros tales como las entidades 540, 550, 560 de terceros, o cualquier número de entidades de terceros adicionales como se ilustra mediante los puntos suspensivos 570. Las entidades 530-570 de terceros pueden ser un ser humano o una organización de seres humanos o puede ser una máquina, un sistema o un dispositivo, o un conjunto de máquinas, dispositivos y/o sistemas. Por ejemplo, si el objeto 420a de datos relativos a DID es un vídeo, el propietario 201 de DID puede no querer que ninguna entidad excepto la entidad 530 de terceros vea el vídeo. Alternativamente, si el objeto 420A de datos relativos a DID es un documento que él o ella ha creado, el propietario 201 de DID puede no querer que ninguna entidad, excepto la entidad 530 de terceros, vea el documento sin alguna forma de pago. En cualquier caso, el propietario 201 de DID puede no querer que la entidad 530 de terceros delegue permiso para usar el objeto de datos relativos a DID sin alguna forma de control sobre tal delegación. Ventajosamente, las realizaciones divulgadas en el presente documento proporcionan una manera de que el propietario 201 de DID controle la delegación de permiso para usar los objetos 420A y/o 420B de datos relativos a DID cuando los objetos de datos se proporcionen a otras entidades de terceros sin la autorización del propietario 201 de DID.
Como se ilustra en la figura 5A, el entorno 500 del sistema informático puede incluir un módulo 510 de delegación. En una realización, el módulo 510 de delegación puede ser implantado por una entidad de terceros tal como el proveedor del módulo 320 de gestión de DID y/o o los concentradores 410 de identidad. En otras realizaciones, el módulo 510 de delegación puede alojarse en un ordenador servidor que esté separado de los dispositivos 301 propiedad del propietario 201 de DID. En otras realizaciones más, el módulo 510 de delegación puede ser parte del módulo 320 de gestión de DID o puede al menos compartir algunas funciones con el módulo 320 de gestión de DID. En realizaciones adicionales, el módulo 510 de delegación puede ser parte o estar alojado en uno de los concentradores 410 de identidad. En consecuencia, las realizaciones divulgadas en el presente documento no están limitadas por dónde se implante el módulo 510 de delegación.
En la realización, el módulo 510 de delegación puede acceder o haberle proporcionado los objetos 420A y/o 420B de datos relativos a DID. Al recibir los objetos 420A y/o 420B de datos relativos a DID, el módulo 510 de delegación puede adjuntar o asociar de otro modo uno o más permisos 520 de delegación con los objetos 420A y/o 420B de datos relativos a DID. Como se explicará con más detalle a continuación, los permisos 520 de delegación pueden especificar una o más interacciones que deben producirse entre el propietario 201 de DID y cualquier entidad de terceros que haya recibido los objetos 420A y/o 420B de datos relativos a DID de la entidad 530 de terceros antes de que las otras entidades de terceros puedan utilizar los objetos 420A y/o 420B de datos relativos a DID. Para facilitar la explicación, los permisos 520 de delegación sólo se explicarán en relación con ser adjuntados al objeto 420A de datos relativos a DID. Sin embargo, esta explicación puede también aplicarse al objeto 420B de datos relativos a DID.
La figura 5B ilustra una realización de ejemplo de los permisos 520 de delegación. Como se ilustra en la realización de ejemplo, los permisos 520 de delegación pueden incluir un primer permiso 521 de delegación, un segundo permiso 522 de delegación, un tercer permiso 523 de delegación y cualquier número de permisos de delegación adicionales como evidencian los puntos suspensivos 524. Cada uno de los permisos 521-524 de delegación puede especificar una interacción específica que debería producirse antes de que las entidades de terceros (es decir, las entidades 540, 550 y 560 de terceros) puedan usar los datos 420A relativos a DID. Se observará que, en otras realizaciones, los permisos 520 de delegación pueden sólo incluir uno o un subconjunto más pequeño de los permisos 521-524 de delegación. A continuación, se explicarán con más detalle ejemplos específicos de las interacciones especificadas o definidas por los permisos 521-524 de delegación.
En algunas realizaciones, los permisos 520 de delegación pueden incluir un permiso 525 de delegación geográfica. El permiso 525 de delegación geográfica puede ser utilizado por el propietario 201 de DID para limitar el área geográfica donde el objeto 420A de datos relativos a DID puede ser utilizado por las entidades 540, 550 y 560 de terceros. Por ejemplo, el propietario 201 de DID puede desear limitar la delegación a su ciudad, estado o país de origen. En consecuencia, las entidades 540, 550 y 560 de terceros no pueden utilizar el objeto 420A de datos relativos a DID fuera del área geográfica especificada por el permiso 525 de delegación geográfica.
En otras realizaciones, los permisos 520 de delegación pueden incluir un permiso 526 de delegación de tiempo. El permiso 526 de delegación de tiempo puede ser utilizado por el propietario 201 de DID para limitar el uso del objeto 420A de datos relativos a DID por parte de entidades 540, 550 y 560 de terceros a un período de tiempo específico. Por ejemplo, el período de tiempo específico puede ser de algunas semanas o meses. Al expirar el tiempo especificado por el permiso 526 de delegación de tiempo, el objeto 420A de datos relativos a DID puede quedar inutilizable por las entidades 540, 550 y 560 de terceros.
Una vez que los permisos 520 de delegación se han adjuntado al objeto 420A de datos relativos a DID, el objeto de datos puede proporcionarse a la entidad 530 de terceros. En este caso, dado que el propietario 201 de DID deseaba que la entidad 530 de terceros pudiera utilizar el objeto 420A de datos relativos a DID, a la entidad 530 de terceros se le proporciona o se le da acceso a la clave pública 207 para que el objeto 420A de datos relativos a DID pueda ser desencriptado. Como se apreciará, es posible que los permisos de delegación 520 no se apliquen normalmente a la entidad 530 de terceros, ya que la entidad 530 estaba destinada a utilizar el objeto 420A de datos relativos a DID. Como se describió anteriormente, los permisos 520 de delegación están adjuntos al objeto 420A de datos relativos a DID de modo que el propietario 201 de DID pueda tener al menos cierto control sobre el uso por entidades de terceros adicionales que reciben el objeto 420A de datos relativos a DID de la entidad 530 de terceros. Sin embargo, en algunas realizaciones el propietario 201 de DID puede incluir permisos que imponen restricciones sobre el uso del objeto 420A de datos relativos a DID por parte de la entidad 530 de terceros en los permisos de delegación 520.
Como se muestra en la figura 5A, la entidad de terceros puede proporcionar el objeto 420A de datos relativos a DID que tiene los permisos de delegación adjuntos 520 a la entidad de terceros 540. Como se muestra, la entidad de terceros 540 puede poseer o estar asociada con un DID 545. Cuando la entidad de terceros 540 intenta usar el objeto 420A de datos relativos a DID, los permisos de delegación 520 pueden especificar las interacciones definidas que deben producirse antes de que se pueda usar el objeto 420A de datos relativos a DID.
Por ejemplo, en una realización supóngase que uno de los permisos 521-524 de delegación especificara una interacción que da como resultado la grabación de un recuento 515A del número de entidades de terceros que reciben el objeto 420A de datos relativos a DID de la entidad 530 de terceros. Esto puede ser útil en aquellos casos en los que el propietario 201 de DID simplemente quiere saber con qué frecuencia se accede al objeto 420A de datos relativos a DID después de haber sido proporcionado a la entidad 530 de terceros y no le preocupa la identidad de la entidad de terceros. En tal realización, el módulo 510 de delegación puede incluir un libro de asientos 515. Alternativamente, el libro de asientos 515 puede almacenarse en el concentrador 411 de identidad o en alguna otra base de datos tal como la base 305 de datos.
En consecuencia, como se muestra en la figura 5A, la entidad 540 de terceros puede proporcionar una interacción 546 al módulo 510 de delegación que informa al módulo de delegación de que la entidad 540 de terceros está intentando utilizar el objeto 420A de datos relativos a DID. Al recibir la interacción 546, el recuento 515A puede escribirse en el libro de asientos 515. Una vez que se ha grabado el recuento 515A, a la entidad 540 de terceros se le puede permitir leer y/o escribir o hacer funcionar o utilizar de otro modo el objeto 420A de datos relativos a DID sin necesidad de ninguna entrada del propietario 201 de DID. En algunas realizaciones, esto puede incluir proporcionar o permitir de otro modo que la entidad 540 de terceros acceda a la clave pública 207 de modo que el objeto 420A de datos relativos a DID pueda ser desencriptado.
En otra realización, además de o como alternativa a los permisos de delegación descritos anteriormente, supóngase que uno de los permisos 521-524 de delegación especifica una interacción que incluye una solicitud para que la entidad 540 de terceros proporcione información histórica de qué entidad recibió el objeto 420A de datos relativos a DID. En la realización, la entidad 540 de terceros puede proporcionar una interacción 546 que informa al módulo 510 de delegación de que el objeto 420A de datos relativos a DID ha sido recibido de la entidad 530 de terceros. Sin embargo, si la entidad 540 de terceros hubiera recibido el objeto 420A de datos relativos a DID de una de las entidades 550 o 560 de terceros después de que esa entidad de terceros hubiera recibido el objeto 420A de datos relativos a DID de la entidad 530 de terceros, esto se incluiría en la interacción 546.
Al recibir la interacción 546, el módulo 510 de regulación puede grabar un historial 516. El historial 516 puede incluir información sobre la identidad de entidades de terceros a las que se les ha proporcionado el objeto 420A de datos relativos a DID. Grabar esta cadena de uso por parte de entidades de terceros puede ser útil en aquellos casos en los que el propietario 201 de DID quiera conocer la identidad de las entidades de terceros que están intentando utilizar el objeto 420A de datos relativos a DID, pero podría no estar interesado en cualquier información adicional sobre las entidades de terceros. Una vez que se ha grabado el historial 516, a la entidad de terceros se le puede permitir usar el objeto 420A de datos relativos a DID, que puede incluir proporcionar acceso a la clave pública 207 para desencriptar el objeto 420A de datos relativos a DID.
Como se muestra en la figura 5A, la entidad 540 de terceros puede proporcionar el objeto 420A de datos relativos a DID, que tiene los permisos 520 de delegación adjuntos, a la entidad 550 de terceros. Como se muestra, la entidad 550 de terceros puede poseer o estar asociada con un DID 555. Cuando la entidad 550 de terceros intenta usar el objeto 420A de datos relativos a DID, los permisos 520 de delegación especificarán las interacciones definidas que han de producirse antes de que se pueda usar el objeto 420A de datos relativos a DID.
En una realización, además o como alternativa a los permisos de delegación descritos anteriormente, supóngase que uno de los permisos 521-524 de delegación especificara una interacción dinámica entre la entidad 550 de terceros y el propietario 201 de DID. Esta interacción dinámica puede ser útil cuando el objeto 420A de datos relativos a DID es de tipo sensible o de un tipo que el propietario 201 de DID puede desear mantener como privado. Por ejemplo, el objeto 420A de datos relativos a DID pueden ser grabaciones médicas o grabaciones financieras que se proporcionaron a la entidad 530 de terceros para un fin específico. Antes de que el propietario 201 de DID conceda el uso a la entidad 550 de terceros, el propietario 201 de DID puede desear determinar quién es la entidad 550 de terceros y por qué la entidad está intentando utilizar el objeto 420<a>de datos relativos a DID.
En consecuencia, el módulo 510 de delegación recibirá una interacción 556 que informe al módulo de delegación que la entidad 550 de terceros está intentando utilizar el objeto 420A de datos relativos a DID. Dado que el objeto 420A de datos relativos a DID es de tipo sensible, un módulo dinámico 518 incluido en el módulo 510 de delegación puede iniciar la interacción dinámica 518A con la entidad 550 de terceros. Por ejemplo, supóngase que el objeto 420A de datos relativos a DID fuera grabaciones médicas. En consecuencia, el módulo dinámico 518 puede solicitar al propietario 201 de DID que haga a la entidad 550 de terceros una serie de preguntas 518A en tiempo real. En la realización, las preguntas en tiempo real podrían incluir preguntar por la identidad de la entidad 550 de terceros y por qué la entidad 550 de terceros necesita usar el objeto 420A de datos relativos a DID. Como también se representa mediante la interacción 556, la entidad 550 de terceros puede responder las preguntas en tiempo real. Por ejemplo, en el caso de las grabaciones médicas, la entidad 550 de terceros puede responder que es un médico y que la entidad 530 de terceros le ha proporcionado el objeto 420A de datos relativos a DID mediante la entidad 540 de terceros como para proporcionar una segunda opinión al propietario 201 de DID y a la entidad 530 de terceros, que puede ser también un médico en este ejemplo.
Si el propietario de DID está conforme con las respuestas dadas y con que a la entidad 550 de terceros se le debería permitir usar el objeto 420A de datos relativos a DID, puede autorizar a que el módulo dinámico 518 permita que la entidad 550 de terceros use el objeto 420A de datos relativos a DID, que puede incluir proporcionar acceso a la clave pública 207 para desencriptar el objeto 420A de datos relativos a DID. Si el propietario 201 de DID no está conforme, entonces puede continuar haciendo más preguntas hasta quedar conforme, o puede ordenarle al módulo dinámico 518 que rechace el uso del objeto 420A de datos relativos a DID. Ventajosamente, requerir la interacción dinámica antes de permitir el uso del objeto 420A de datos relativos a DID permite al propietario 201 de DID determinar en tiempo real si a un tercero, al que se le ha proporcionado el objeto 420A de datos relativos a DID desde la entidad 530 de terceros, debería permitírsele el uso del objeto 420A de datos relativos a DID.
Como se muestra en la figura 5A, la entidad 540 de terceros puede proporcionar el objeto 420A de datos relativos a DID que tiene los permisos de delegación adjuntos a la entidad 560 de terceros. Alternativamente, o además de, el objeto 420A de datos relativos a DID puede ser proporcionado por la entidad 550 de terceros. Como se muestra, la entidad 560 de terceros puede poseer o estar asociada con un DID 565. Cuando la entidad 560 de terceros intenta utilizar el objeto 420A de datos relativos a DID, los permisos 520 de delegación pueden especificar las interacciones definidas que tienen que producirse antes de que se pueda usar el objeto 420A de datos relativos a DID.
En una realización, además o como alternativa a los permisos de delegación descritos anteriormente, supóngase que uno de los permisos 521-524 de delegación especificara que se proporcionara el pago de una tarifa antes de que se pueda utilizar el objeto 420A de datos relativos a DID. Esto puede ser útil en aquellos casos en los que el objeto 420A de datos relativos a DID puede ser de un tipo tal como un libro o una película que el propietario 201 de DID puede querer vender a entidades distintas a la entidad 530 de terceros, o si el propietario 201 de DID quiere simplemente ganar dinero con el objeto 420A de datos relativos a DID.
En consecuencia, el módulo 510 de delegación puede recibir una interacción 566 que informe al módulo de delegación de que la entidad 560 de terceros está intentando utilizar el objeto 420A de datos relativos a DID. Dado que el permiso de delegación requiere el pago de una tarifa, un módulo 517 de pago incluido en el módulo 510 de delegación puede solicitar un pago 517A de la entidad 560 de terceros. Como también se representa mediante la interacción 566, la entidad 560 de terceros puede entonces proporcionar un pago al módulo 517 de pago. Tras la verificación del pago, el módulo 517 de pago puede permitir que la entidad 560 de terceros use el objeto 420A de datos relativos a DID, que puede incluir proporcionar acceso a la clave pública 207 para desencriptar el objeto 420A de datos relativos a DID.
El siguiente análisis se refiere ahora a una serie de métodos y de actos de método que se pueden realizar. Aunque los actos de método pueden analizarse en un orden determinado o ilustrarse en un diagrama de flujo como si se produjeran en un orden particular, no se requiere ningún orden particular a menos que se indique específicamente, o que se requiera porque un acto depende de que otro acto se complete antes de que se realice el acto.
La figura 6 ilustra un diagrama de flujo de un método 600 de ejemplo para que un propietario de DID controle el uso delegado de datos relativos a DID. El método 600 se describirá con respecto a una o más de las figuras 1-5B analizadas anteriormente.
El método 600 incluye el acto de adjuntar permisos de delegación a uno o más objetos de datos relativos a DID que van a ser proporcionados por un propietario de DID a una primera entidad de terceros, especificando, los permisos de delegación, al menos una o más interacciones que tienen que producirse entre el propietario de DID y una o más segundas entidades de terceros que han recibido el uno o más objetos de datos relativos a DID de la primera entidad de terceros antes de que la una o más segundas entidades de terceros puedan usar el uno o más objetos de datos relativos a DID (acto 610). Por ejemplo, como se describió anteriormente, el módulo 510 de delegación puede adjuntar los permisos 520 de delegación, incluidos uno o más permisos 521-526 de delegación, a los objetos 420A y/o 420B de datos relativos a DID. Los permisos 520 de delegación especifican diversas interacciones, tales como las interacciones 546, 556 y 566, que han de producirse antes de que entidades de terceros, tales como entidades de terceros 540, 550 y 560, que han recibido los objetos 420A y/o 420B de datos relativos a DID de la entidad 530 de terceros, puedan usar los objetos 420A y/o 420B de datos relativos a DID. Las entidades 540, 550 y 560 de terceros pueden recibir los objetos 420A y/o 420B de datos relativos a DID directamente de la entidad 530 de terceros o indirectamente de la entidad 530 de terceros mediante otra de las entidades 540, 550 y 560 de terceros que ha recibido los objetos de datos de la entidad 530 de terceros.
El método 600 incluye, después de adjuntar los permisos de delegación, el acto de proporcionar el uno o más objetos de datos relativos a DID a la primera entidad de terceros (acto 620). Por ejemplo, como se describió anteriormente, el módulo 510 de delegación puede proporcionar los objetos 420A y/o 420B de datos relativos a DID a la entidad 530 de terceros después de adjuntar los permisos 520 de delegación.
El método 600 incluye el acto de recibir una o más interacciones de la una o más segundas entidades de terceros cuando la una o más segundas entidades de terceros intentan utilizar el uno o más objetos de datos relativos a DID (acto 630). Por ejemplo, como se describió anteriormente, el módulo 510 de delegación puede recibir una de las interacciones 546, 556 y 566 de una de las entidades 540, 550 y 560 de terceros cuando la entidad de terceros intenta usar los objetos 420A y/o 420B de datos relativos a DID.
El método 600 incluye el acto de permitir que la una o más segundas entidades de terceros utilicen uno o más objetos de datos relativos a DID cuando la una o más interacciones recibidas satisfacen los permisos de delegación (acto 640). Por ejemplo, como se describió anteriormente, el módulo 510 de delegación puede permitir el uso de los objetos 420A y/o 420B de datos relativos a DID cuando se han satisfecho los permisos 520 de delegación. En algunas realizaciones, esto puede incluir proporcionar acceso a la clave pública 207 para que los objetos 420A y/o 420B de datos relativos a DID puedan ser desencriptados.

Claims (10)

REIVINDICACIONES
1. Un sistema informático (100, 200, 300, 400, 500) que está implantado en una red descentralizada (200) que implanta un libro de asientos distribuido (220), estando configurado el libro de asientos distribuido para respaldar una o más identidades descentralizadas, DID, para uno o más usuarios del sistema informático, comprendiendo el sistema informático:
uno o más procesadores (102); y
uno o más medios legibles por ordenador (104) que tienen en ellos instrucciones ejecutables por ordenador (106) que están estructuradas de tal manera que, cuando son ejecutadas por el uno o más procesadores, hacen que el sistema informático:
adjunte (610) permisos (520, 521, 522, 523, 524, 525, 526) de delegación a uno o más objetos (420A, 420B) de datos relativos a DID que van a ser proporcionados por un propietario (201) de DID a una primera entidad (530) de terceros, especificando los permisos de delegación al menos una o más interacciones (546, 556, 566) que van a producirse entre el propietario de DID y una o más segundas entidades (540, 550, 560) de terceros que han recibido el uno o más objetos de datos relativos a DID de la primera entidad de terceros antes de que la una o más segundas entidades de terceros puedan utilizar el uno o más objetos de datos relativos a DID;
después de adjuntar los permisos de delegación, proporcione (620) el uno o más objetos de datos relativos a DID a la primera entidad de terceros;
reciba (630) una o más interacciones de la una o más segundas entidades de terceros cuando la una o más segundas entidades de terceros intentan utilizar el uno o más objetos de datos relativos a DID; y
permita (640) que la una o más segundas entidades de terceros utilicen el uno o más objetos de datos relativos a DID cuando la una o más interacciones recibidas satisfacen los permisos de delegación.
2. El sistema informático de acuerdo con la reivindicación 1, en el que la una o más interacciones comprenden grabar un recuento (515A) del número de segundas entidades de terceros que intentan utilizar el uno o más objetos de datos relativos a DID.
3. El sistema informático de acuerdo con la reivindicación 1, en el que la una o más interacciones comprenden una solicitud para que una segunda entidad de terceros específica proporcione información histórica (516) sobre otras entidades de terceros que han utilizado el uno o más objetos de datos relativos a DID.
4. El sistema informático de acuerdo con la reivindicación 1, en el que el uno o más permisos de delegación especifican que la una o más segundas entidades de terceros van a estar dentro de una ubicación especificada (525) cuando se intente utilizar el uno o más datos relativos a DID o especifican que la una o más segundas entidades de terceros tienen que utilizar el uno o más objetos de datos relativos a DID dentro de un período especificado (526) de tiempo.
5. El sistema informático de acuerdo con la reivindicación 1, en el que la una o más interacciones comprenden recibir el pago de una tarifa especificada (517) de la una o más segundas entidades de terceros antes de permitir el uso del uno o más objetos de datos relativos a DID.
6. El sistema informático de acuerdo con la reivindicación 1, en el que la una o más interacciones comprenden recibir dinámicamente (518) información adicional de la una o más segundas entidades de terceros antes de que la una o más segundas entidades de terceros puedan usar el uno o más objetos de datos relativos a DID.
7. El sistema informático de acuerdo con la reivindicación 7, en el que la recepción dinámica de información adicional se basa en un tipo del uno o más objetos de datos relativos a DID.
8. El sistema informático de acuerdo con la reivindicación 1, en el que la una o más segundas entidades de terceros reciben el uno o más objetos de datos relativos a DID ya sea directamente de la primera entidad de terceros o de una o más otras segundas entidades de terceros.
9. El sistema informático de acuerdo con la reivindicación 1, en el que permitir el uso del uno o más objetos de datos relativos a DID comprende proporcionar acceso a una clave pública (207) que está configurada para desencriptar el uno o más objetos relativos a DID.
10. En un sistema informático que se implanta en una red descentralizada que implanta un libro de asientos distribuido, siendo configurado el libro de asientos distribuido para respaldar una o más identidades descentralizadas, DID, para uno o más usuarios del sistema informático, un método para un propietario de DID para controlar el uso delegado de datos relativos a DID, comprendiendo el método:
un acto de adjuntar (610) permisos (520, 521, 522, 523, 524, 525, 526) de delegación a uno o más objetos (420A, 420B) de datos relativos a DID que van a ser proporcionados por un propietario (201) de DID a una primera entidad (530) de terceros, especificando los permisos de delegación al menos una o más interacciones (546, 556, 566) que van a producirse entre el propietario de DID y una o más segundas entidades (540, 550, 560) de terceros que han recibido el uno o más objetos de datos relativos a DID de la primera entidad de terceros antes de que la una o más segundas entidades de terceros puedan utilizar el uno o más objetos de datos relativos a DID;
después de adjuntar los permisos de delegación, un acto de proporcionar (620) el uno o más objetos de datos relativos a DID a la primera entidad de terceros;
un acto de recibir (630) una o más interacciones de la una o más segundas entidades de terceros cuando la una o más segundas entidades de terceros intentan utilizar el uno o más objetos de datos relativos a DID; y
un acto de permitir (640) que la una o más segundas entidades de terceros utilicen el uno o más objetos de datos relativos a DID cuando la una o más interacciones recibidas satisfacen los permisos de delegación.
ES20735818T 2019-09-05 2020-06-17 Control del uso delegado de datos relativos a los identificadores descentralizados o DID Active ES2961364T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/561,510 US11184334B2 (en) 2019-09-05 2019-09-05 Control of the delegated use of DID-related data
PCT/US2020/038003 WO2021045821A1 (en) 2019-09-05 2020-06-17 Control of the delegated use of did-related data

Publications (1)

Publication Number Publication Date
ES2961364T3 true ES2961364T3 (es) 2024-03-11

Family

ID=71409584

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20735818T Active ES2961364T3 (es) 2019-09-05 2020-06-17 Control del uso delegado de datos relativos a los identificadores descentralizados o DID

Country Status (5)

Country Link
US (1) US11184334B2 (es)
EP (1) EP4026291B1 (es)
CN (1) CN114341855A (es)
ES (1) ES2961364T3 (es)
WO (1) WO2021045821A1 (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210314293A1 (en) * 2020-04-02 2021-10-07 Hewlett Packard Enterprise Development Lp Method and system for using tunnel extensible authentication protocol (teap) for self-sovereign identity based authentication
CN113012008B (zh) * 2020-09-15 2022-06-03 支付宝(杭州)信息技术有限公司 一种基于可信硬件的身份管理方法、装置及设备
JP7180038B1 (ja) * 2021-04-06 2022-11-29 株式会社ワコム アートワーク管理方法、コンピュータ、及びプログラム
US11804966B2 (en) * 2021-05-31 2023-10-31 Microsoft Technology Licensing, Llc Trusted custody chain for verifiable claims

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9674194B1 (en) 2014-03-12 2017-06-06 Amazon Technologies, Inc. Privilege distribution through signed permissions grants
US20170324711A1 (en) * 2016-05-03 2017-11-09 The Real Mccoy, Llc Inc. Method for establishing, securing and transferring computer readable information using peer-to-peer public and private key cryptography
US11159315B2 (en) 2018-01-22 2021-10-26 Microsoft Technology Licensing, Llc Generating or managing linked decentralized identifiers
WO2020081727A1 (en) * 2018-10-16 2020-04-23 Eluvio, Inc. Decentralized content fabric
US11281394B2 (en) * 2019-06-24 2022-03-22 Pure Storage, Inc. Replication across partitioning schemes in a distributed storage system

Also Published As

Publication number Publication date
US20210075774A1 (en) 2021-03-11
WO2021045821A1 (en) 2021-03-11
EP4026291B1 (en) 2023-09-20
US11184334B2 (en) 2021-11-23
CN114341855A (zh) 2022-04-12
EP4026291A1 (en) 2022-07-13

Similar Documents

Publication Publication Date Title
ES2965062T3 (es) Gestión de certificaciones
US11176282B2 (en) Encrypting data associated with decentralized identifier
ES2961364T3 (es) Control del uso delegado de datos relativos a los identificadores descentralizados o DID
US11251977B2 (en) Validation data structure for decentralized identity claim
CN112673372A (zh) 去中心化的系统中的私有和公共媒体数据
US11429743B2 (en) Localization of DID-related claims and data
US11238170B2 (en) Delegation using pairwise decentralized identifier
US11392467B2 (en) Failover between decentralized identity stores
US11128457B2 (en) Cryptographic key generation using external entropy generation
US11587084B2 (en) Decentralized identification anchored by decentralized identifiers
US11916919B2 (en) Resolving decentralized identifiers using multiple resolvers
US11411736B2 (en) Automatic renewal of a verifiable claim
US20200380144A1 (en) Quick actions for did attestation user interface elements
US11394713B2 (en) Did delegation/revocation to another DID
US20230050460A1 (en) Issuing verifiable pairwise claims