ES3031963T3

ES3031963T3 - Digital identity

Info

Publication number: ES3031963T3
Application number: ES21203787T
Authority: ES
Inventors: Eleanor Simone Frederika Loughlin-Mchugh; Romek Edward Szczesniak
Original assignee: Yoti Holding Ltd
Current assignee: Yoti Holding Ltd
Priority date: 2015-02-13
Filing date: 2016-02-12
Publication date: 2025-07-14
Anticipated expiration: 2036-02-12
Also published as: WO2016128567A1; EP3754939A1; EP3257221B1; EP4525372A3; WO2016128569A1; CN107637015A; CN107636662A; EP4525372A2; EP3257222A1; EP3968194B1; EP3754939B1; PT3968194T; EP3257222B1; EP3579524A1; EP3579524B1; EP3257223B1; WO2016128568A1; EP3968194A1; EP3257221A1; EP3257223A1

Abstract

Se proporciona un sistema de identidad digital que comprende una interfaz informática para recibir mensajes electrónicos y uno o más procesadores de hardware configurados para ejecutar un módulo de registro, un módulo de creación de credenciales y un servicio de validación. El módulo de registro está configurado para recibir datos capturados de un documento de identidad y crear una identidad digital que los contiene. El módulo de creación de credenciales está configurado para transmitir a un dispositivo de usuario, a través de la interfaz informática, una credencial que se almacenará en el dispositivo de usuario y que estará vinculada a la identidad digital. El servicio de validación está configurado para recibir un mensaje electrónico que contiene la credencial e identifica un dispositivo de destino, validarla y, si es válida, utilizarla para transmitir desde el sistema de identidad digital al dispositivo de destino un mensaje electrónico que pone los datos de la identidad digital a disposición del dispositivo de destino. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Identidad digital

Antecedentes

De vez en cuando, las personas necesitan demostrar algún aspecto de su identidad y, a menudo la forma más convincente de hacerlo es con un pasaporte u otro ID nacional con fotografía tal como una licencia de conducción o (en las jurisdicciones que los exigen) una tarjeta de identidad. Sin embargo, si bien estos documentos son de gran fiabilidad debido a la dificultad que implica hacer copias fraudulentas y su emisión por parte de las instituciones gubernamentales, también son lo suficientemente valiosos como para que sea preferible no tener que llevarlos a todas partes.

El documento US2014/279519A1 divulga un método de identificación de un usuario para transacciones que incluyen recibir una imagen de un documento de identificación del usuario durante una primera transacción con una primera parte, en la que la imagen se obtiene utilizando un módulo de adquisición de imágenes de un dispositivo del usuario, recibir un ID de dispositivo del dispositivo del usuario, extraer credenciales de identificación del usuario de la imagen, almacenar las credenciales de identificación del usuario y el ID de dispositivo del dispositivo del usuario en un servidor.

El documento US2003/084288A1 divulga un método para gestionar la identificación en una red de comunicaciones de datos.

Resumen

De acuerdo con un primer aspecto, un sistema de identidad digital para crear una identidad digital almacenada por ordenador comprende: una interfaz de red configurada para enviar y recibir mensajes electrónicos; almacenamiento electrónico persistente; un módulo de gestión de perfiles configurado para recibir desde una entidad un mensaje electrónico que comprende un ítem de datos, extraer el ítem de datos del mensaje electrónico y almacenar el ítem de datos en un perfil digital en el almacenamiento electrónico persistente; un módulo de creación de credenciales configurado para generar una credencial para el perfil y asociar la credencial con el perfil digital; un módulo de publicación configurado para publicar el perfil al almacenar una versión del mismo en una ubicación de memoria direccionable; y un módulo de generación de recibos configurado para generar automáticamente dos recibos no coincidentes, cada recibo comprende un identificador de transacción, un primero de los recibos comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil, un segundo de los recibos comprende la credencial, en la que el primer recibo se almacena en el sistema de identidad digital y el segundo recibo se transmite a una dirección asociada con la entidad. También se proporciona un método correspondiente.

El mecanismo de creación de perfiles de la presente invención proporciona tanto un recibo para la auditoría interna por el sistema de identidad digital, como una credencial para uso posterior por el usuario.

Una vez creado, el perfil se puede utilizar por la entidad para confirmar su identidad a otra entidad (validador) en lugar de un documento de identidad del mundo real. La otra entidad puede acceder al perfil publicado para confirmar los detalles relevantes de la entidad a partir del ítem de datos y de cualesquier otros ítems de datos del perfil.

Preferiblemente, la presentación de la credencial al sistema de identidad digital por una entidad presentadora hace que el perfil publicado esté disponible para una entidad presentadora (en las realizaciones, esto puede de hecho desencadenar la publicación). Por lo tanto, la entidad puede proporcionar su credencial a la entidad presentadora como una forma de confirmar su identidad, como se incorpora en el perfil, a la entidad presentadora. Es decir, la credencial digital se puede utilizar como un sustituto de un documento de identidad del mundo real.

El ítem de datos puede ser, por ejemplo, una imagen visual de la entidad. En el caso de una entidad humana, puede ser una foto de su cara capturada a partir de, o que se sabe que coinciden con, una fotografía de identificación de un documento de identificación del mundo real, tal como un pasaporte o una licencia de conducción. Esto se puede capturar utilizando una cámara y/o tecnología inalámbrica (NFC, Bluetooth, etc.) si un chip electrónico adecuado está integrado en el documento. La otra entidad puede verificar que el usuario es quien dice ser al comparar visualmente la cara real del usuario con la del perfil publicado. También se pueden recibir y almacenar en el perfil otros ítems de datos como el nombre del usuario, datos de nacimiento, nacionalidad, etc. del documento de identidad. Se pueden crear múltiples perfiles para un usuario, que pueden ser únicos, pero no obstante, comparten algunos ítems de datos. Por ejemplo, un perfil básico puede tener solo un ítem de datos (por ejemplo, una foto), y el(los) perfil(es) adicional(es) puede(n) tener la foto más diversos grados de datos de usuario adicionales (nombre, nombre y fecha de nacimiento, nombre y fecha de nacimiento y nacionalidad, etc.).

Al publicar la versión de los perfiles en lugar de permitir el acceso directo a los perfiles, se preserva la seguridad de los perfiles ya que los perfiles subyacentes nunca son visibles fuera del sistema de identidad digital.

Se puede generar un recibo cada vez que se realice una transacción que involucre el perfil. Dichos recibos proporcionan una pista de auditoría, mediante la cual la actividad histórica de la entidad es visible dentro del sistema. Por ejemplo, los recibos se pueden utilizar para aislar la actividad fraudulenta histórica de una entidad humana (usuario). Cuando el ítem de datos es una imagen visual de la cara del usuario, esto facilita el enlace inequívoco de dicha actividad con un humano real. Preferiblemente, el perfil se vuelve a publicar en cada transacción para proporcionar una “ instantánea” del perfil tal como estaba en ese momento, que no se vea afectada por futuras modificaciones. Esto garantiza una pista de auditoría precisa, mediante la cual la actividad en cualquier momento anterior se puede aislar con precisión.

Preferiblemente, el perfil se publica tras la presentación de la credencial al sistema de identidad digital, por ejemplo, por el validador, de tal manera que el perfil solo sea accesible para el validador cuando presente la credencial.

A efectos de auditoría, se puede generar un recibo maestro que comprenda datos de cada recibo en las realizaciones y almacenarlo en un libro de recibos maestro en el sistema de identidad digital. Es decir, tanto el primero como el recibo maestro se pueden almacenar por separado en el sistema de identidad digital. El recibo maestro puede comprender solo una parte del primer recibo, por ejemplo, el enlace, pero no la credencial.

En ciertas realizaciones, sin embargo, puede comprender un hash (por ejemplo, HMAC) de la credencial. Es decir, un valor generado al aplicar una función hash criptográfica (por ejemplo, HMAc ) a la credencial. La función hash es irreversible, en el sentido de que es imposible recuperar la propia credencial a partir del hash de la credencial. Sin embargo, si el usuario pone a disposición del sistema la credencial original más adelante, el hash se puede volver a calcular a partir de la credencial disponible y el valor resultante se puede utilizar para ubicar el recibo maestro. Esto puede permitir, por ejemplo, la interceptación legal de recibos sin comprometer su seguridad.

Al menos parte del recibo maestro (al menos el enlace) y/o la versión publicada del perfil se pueden cifrar con el identificador de transacción, en cuyo caso el maestro no incluye el identificador de transacción. Es decir, el identificador de transacción se puede utilizar como una clave criptográfica para cifrar el enlace y/o el propio perfil publicado. Esto significa que solo el titular del recibo puede acceder al perfil publicado que comprende el identificador de transacción, y no se puede acceder solo utilizando el recibo maestro.

Preferiblemente, la credencial es una credencial aleatoria de un solo uso, que solo se puede utilizar para efectuar una sola transacción y deja de ser válida a partir de entonces. Esto vincula la credencial a la creación del perfil específicamente. A continuación, se necesitarán credenciales similares de un solo uso cada vez que la entidad acceda posteriormente al perfil y/o lo modifique, o cree un nuevo perfil, de tal manera que todas las credenciales estén vinculadas a una transacción específica.

Preferiblemente, los metadatos disponibles para un dispositivo informático que envía el mensaje electrónico se incluyen en el mensaje. Los metadatos pueden ser metadatos del propio dispositivo, por ejemplo, un identificador de dispositivo (ID), tal como un número de serie o una dirección MAC del dispositivo, o pueden ser metadatos relacionados, tales como datos de (geo)localización (por ejemplo, GPS) que identifican una (geo)localización del dispositivo cuando se envió el mensaje. Los metadatos se pueden utilizar para generar la credencial, por ejemplo, como un hash de los metadatos y una secuencia aleatoria (semilla). Esto puede dar lugar a que una credencial tiene un tamaño de bits grande, por lo que se produce un ahorro significativo de memoria al almacenar los “ ingredientes” utilizados para crear la credencial en el sistema de identidad digital en lugar de la credencial en sí misma. A continuación, se puede crear una copia de la credencial cuando sea necesario, por ejemplo para determinar si una credencial presentada al sistema coincide con la original (el acceso al perfil publicado solo se puede conceder si este es el caso). La semilla y los metadatos se pueden aplicar a hash un número aleatorio de veces, y los ingredientes almacenados también incluyen este número aleatorio.

Cuando los metadatos comprenden un ID de dispositivo para el perfil solo se puede conceder si la credencial se presenta junto con un ID de dispositivo coincidente. Por lo tanto, el uso de la credencial está restringido a ese dispositivo para mayor seguridad (si el usuario desea utilizar múltiples dispositivos para confirmar su identidad, entonces puede solicitar una credencial independiente para cada dispositivo, cada credencial unida al perfil).

El perfil también puede tener un valor de confianza asignado, que es indicativo de la confianza que tiene el sistema en que la entidad tiene realmente la identidad que está confirmando. El valor de confianza está disponible preferiblemente con el perfil publicado, por ejemplo se puede incluir y publicar con el propio perfil en la misma ubicación de memoria. Por lo tanto, al validador no se le indica simplemente que la entidad es quien o lo que dice ser, sino que también se le informa cuán confiable considera el sistema de identidad digital que ese sea el caso. El valor de confianza puede ser una métrica fácilmente interpretable tal como un valor entre 0 y 1 (o 0 % y 100 %), 0(%) que representa incertidumbre completa y 1(00 %) que representa certeza total, aunque esto último es poco probable en la práctica. El valor de confianza puede cambiar con el tiempo. Por ejemplo a medida que el usuario carga más ítems de datos, por ejemplo fotos de su cara (“selfies”) que, en algunas realizaciones, pueden ser necesarias para iniciar sesión en el sistema de identidad digital y ser almacenadas en el sistema de identidad digital cada vez, esto puede confirmar una influencia positiva en el valor de confianza, al hacer que aumente (al menos en ausencia de otras influencias), siempre que las fotos coincidan (mientras que las fotos para las que la coincidencia es cuestionable pueden tener el efecto contrario). De manera similar, a medida que la entidad completa una transacción adicional, esto puede ejercer una influencia positiva similar. Por el contrario, cuando el(los) ítem(s) de datos en el perfil digital se capturan de, por ejemplo, un documento de identificación del mundo real, a medida que el documento envejece esto puede ejercer una influencia negativa en el valor de confianza, lo que hace que disminuya (al menos en ausencia de otras influencias). Muchas de estas influencias se pueden agregar, por lo que el valor de confianza refleja una confianza general.

Para capturar los datos relevantes, un segundo aspecto proporciona un método de registro de una identidad digital que comprende: capturar en un dispositivo informático un ítem de datos asociado con una entidad; crear un mensaje electrónico que comprende el ítem de datos; transmitir el mensaje electrónico a un servicio de registro; recibir un recibo del servicio de registro; extraer una credencial del recibo para hacer que la credencial esté disponible para acceder al ítem de datos para autenticar la entidad; y almacenar el recibo en un libro de recibos local en una ubicación accesible para el dispositivo informático.

En el caso de que los datos relevantes se capturen de un documento de identidad, un tercer aspecto proporciona un método implementado al ejecutar el software de identidad digital en un procesador de un dispositivo de usuario (por ejemplo, un dispositivo inteligente tal como un teléfono inteligente o un ordenador tipo tableta) para: capturar con una cámara del dispositivo del usuario una imagen de la cara de un usuario del dispositivo; capturar datos de un documento de identidad del mundo real (tal como una licencia de conducción o un pasaporte), los datos incluyen una fotografía de identificación, en la que los datos se capturan con la cámara, desde un transmisor electrónico integrado en el documento de anclaje, o una combinación de ambos; transmitir la imagen del usuario y los datos capturados a un sistema de identificación digital; y recibir desde el sistema de identificación digital una credencial para el usuario, en el que la presentación de la credencial al sistema de identidad digital hace que al menos parte de los datos capturados estén disponibles para una entidad presentadora.

Los datos capturados también comprenden un atributo del documento, por ejemplo suficientes datos para poder confirmar con una certeza razonable un tipo de documento (por ejemplo, licencia de conducción, pasaporte, etc.) y, posiblemente, para poder determinar si o no el documento parece auténtico.

Desde el punto de vista del sistema, un cuarto aspecto proporciona un método implementado por ordenador implementado por un sistema de identidad digital, que comprende: recibir en un mensaje electrónico de un dispositivo de usuario: una imagen de la cara de un usuario del dispositivo de usuario que se ha capturado en el dispositivo de usuario; y los datos que se han capturado de un documento de identidad del mundo real y que comprenden una fotografía de identificación; almacenar al menos parte de los datos capturados en el sistema de identidad digital en el almacenamiento electrónico persistente; comparar la imagen de la cara con la fotografía de identidad utilizando un algoritmo de verificación facial; solo si la imagen de la cara coincide con la fotografía de identificación, generar una credencial para el usuario y transmitir la credencial al usuario, en la que la presentación de la credencial al sistema de identidad digital hace que al menos parte de los datos almacenados estén disponibles para una entidad presentadora.

El uso de la verificación facial de esta manera garantiza que los usuarios solo puedan utilizar sus propios documentos de identidad como base para una identidad digital dentro del sistema. La imagen de su cara y/o la fotografía capturada del documento de identidad se presenta a la entidad presentadora, lo que es particularmente aplicable cuando un humano se identifica a sí mismo con otro humano en el mundo real.

Cuando también se recibe un atributo del documento, la generación y transmisión de la credencial solo puede tener lugar si el atributo coincide con algunos criterios predeterminados. Por ejemplo, en el caso de un pasaporte, el atributo puede ser caracteres capturados desde una zona legible por máquina (MRZ) y la condición puede ser que estos tengan un formato válido.

De acuerdo con varios aspectos de la presente invención, se confirma una identidad utilizando un perfil digital. Por ejemplo, se puede crear un perfil a partir de datos capturados de un documento de identidad del mundo real tal como un pasaporte o una licencia de conducción, que preferiblemente comprende una fotografía de identificación del documento. Una vez creado, el perfil se puede utilizar por la entidad para confirmar su identidad a otra entidad (validador).

En otro aspecto, un método de autenticación de una credencial digital de un portador por un dispositivo de validación comprende: capturar la credencial del portador por el dispositivo de validación; transmitir a un servicio de validación la credencial de portador con una credencial de validador unida al dispositivo de validación; en el servicio de validación, validar la credencial de portador y la credencial de validación, y si la credencial de validador es válida, utilizar la credencial de portador para acceder a un ítem de datos de un perfil digital y crear un mensaje electrónico para transmisión al dispositivo de validación, el mensaje electrónico que indica el ítem de datos y que comprende una nueva credencial de validador generada por el servicio de validación; emitir una nueva credencial de portador y crear un mensaje electrónico para transmitir la nueva credencial de portador a una dirección asociada con el portador.

Preferiblemente, el método también comprende la etapa de utilizar la credencial del validador para acceder a un ítem de datos de un perfil digital asociado con el dispositivo de validación y crear un mensaje electrónico para transmisión al portador, el mensaje electrónico indica un ítem de datos para verificación por el portador. De esta manera, una sola transacción proporciona autenticación bidireccional - el validador no solo puede autenticar al portador utilizando el ítem de datos del perfil del portador, sino que el portador también puede validar al validador. Por lo tanto, una sola transacción les dice a ambas entidades si deben creer o no que la otra es quien o lo que afirma ser. Esto surge de la novedosa combinación de que el validador presenta su propia credencial y la del portador juntas, y cada entidad consigue un ítem de datos respectivo para la otra entidad. El ítem de datos relacionado con el validador se envía al portador mediante señalización fuera de banda, por ejemplo, a un dispositivo que tiene una dirección asociada con la credencial del portador en el sistema de identidad digital.

En otro aspecto, un método para proporcionar acceso a los perfiles digitales mantenidos en el almacenamiento electrónico persistente de un sistema de identidad digital comprende: recibir desde una entidad solicitante un mensaje de solicitud electrónica que identifique a una entidad objetivo; en respuesta a la solicitud, publicar: (i) un perfil digital de la entidad objetivo al almacenar una versión de ese perfil en una ubicación de memoria direccionable, y (ii) un perfil digital de la entidad solicitante al almacenar una versión de ese perfil en otra ubicación de memoria direccionable; generar dos recibos no coincidentes, cada uno de los cuales comprende un identificador de transacción, el primero de los cuales comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil de la entidad objetivo, el segundo de los cuales comprende un enlace que identifica la otra ubicación de memoria en la que se publica el perfil de la entidad solicitante; transmitir el primer recibo a una dirección asociada con la entidad solicitante; y transmitir el segundo recibo a una dirección asociada con la entidad objetivo.

Cada entidad puede validar a la otra en base a el perfil publicado relevante en una sola transacción.

Al publicar una versión del perfil en lugar de permitir el acceso directo al perfil, se preserva la seguridad del perfil ya que el perfil subyacente nunca es visible fuera del sistema de identidad digital.

Un enlace, tal como un Indicador Uniforme de Recursos (URI), que identifica la ubicación de la memoria direccionable se puede transmitir al dispositivo presentador.

El enlace se puede generar a partir de una secuencia aleatoria y/o la ubicación de la memoria direccionable se puede seleccionar en base a una secuencia aleatoria. La generación aleatoria de enlaces/selección de direcciones de memoria garantiza un uso eficiente de la dirección de memoria/espacio de enlace.

El ítem de datos puede ser por ejemplo una imagen visual de la entidad. En el caso de una entidad humana, puede ser una foto de su cara capturada a partir de, o que se sabe coincide con, una fotografía de identificación de un documento de identificación del mundo real tal como un pasaporte o una licencia de conducción. Esto se puede capturar utilizando una cámara y/o tecnología inalámbrica (NFC, Bluetooth, etc.) si un chip electrónico adecuado está integrado en el documento. La otra entidad puede verificar que el usuario es quien dice ser al comparar visualmente la cara real del usuario con la del perfil publicado. También se pueden recibir y almacenar en el perfil otros ítems de datos como el nombre del usuario, datos de nacimiento, nacionalidad, etc. del documento de identidad. Se pueden crear múltiples perfiles para un usuario, que pueden ser únicos, pero que no obstante comparten algunos ítems de datos. Por ejemplo, un perfil básico puede tener solo un ítem de datos (por ejemplo, una foto), y el(los) perfil(es) adicionales pueden tener la foto más diversos grados de datos de usuario adicionales (nombre, nombre y fecha de nacimiento, nombre y fecha de nacimiento y nacionalidad, etc.).

Preferiblemente, los metadatos disponibles para un dispositivo informático que envía el mensaje electrónico se incluyen en el mensaje. Los metadatos pueden ser metadatos del propio dispositivo, por ejemplo, un identificador de dispositivo (ID), tal como un número de serie o una dirección MAC del dispositivo, o pueden ser metadatos relacionados, tales como datos de (geo)localización (por ejemplo, GPS) que identifican una (geo)localización del dispositivo cuando se envió el mensaje. Los metadatos se pueden utilizar para generar la credencial, por ejemplo, como un hash de los metadatos y una secuencia aleatoria (semilla). Esto puede dar lugar a que una credencial tenga un tamaño de bits grande, por lo que se produce un ahorro significativo de memoria al almacenar los “ ingredientes” utilizados para crear la credencial en el sistema de identidad digital en lugar de la credencial en sí misma. A continuación, se puede crear una copia de la credencial cuando sea necesario, por ejemplo para determinar si una credencial presentada al sistema coincide con la original (el acceso al perfil publicado solo se puede conceder si este es el caso). La semilla y los metadatos pueden ser aplicados a un hash un número aleatorio de veces, y los ingredientes almacenados también incluyen este número aleatorio.

Cuando los metadatos comprenden un ID de dispositivo para el perfil, solo se puede conceder si la credencial se presenta junto con un ID de dispositivo coincidente. Por lo tanto, el uso de la credencial está restringido a ese dispositivo para mayor seguridad (si el usuario desea utilizar múltiples dispositivos para confirmar su identidad, entonces puede solicitar una credencial separada para cada dispositivo, cada credencial unida al perfil).

A efectos de auditoría, se puede generar un recibo maestro que comprenda datos de cada recibo en las realizaciones y almacenarlo en un libro de recibos maestro en el sistema de identidad digital. Es decir, tanto el primero como el recibo maestro se pueden almacenar por separado en el sistema de identidad digital. El recibo maestro puede comprender solo una parte del primer recibo, por ejemplo el enlace y el identificador de transacción, pero no la credencial.

Preferiblemente, cada credencial es una credencial aleatoria de un solo uso, que solo se puede utilizar para efectuar una sola transacción y deja de ser válida a partir de entonces. Esto vincula la credencial a la creación de un perfil específicamente. A continuación, se necesitarán credenciales de uso único similares cada vez que la entidad acceda posteriormente y/o modifique el perfil y o cree un nuevo perfil, de tal manera que todas las credenciales estén vinculadas a una transacción específica.

El perfil también puede tener un valor de confianza asignado, que es indicativo de la confianza que tiene el sistema en que la entidad tiene realmente la identidad que está confirmando. El valor de confianza está disponible preferiblemente con el perfil publicado, por ejemplo, se puede incluir y publicar con el propio perfil en la misma ubicación de memoria. Por lo tanto, al validador no se le indica simplemente que la entidad es quien o lo que dice ser, sino que también se le informa cuán confiable considera el sistema de identidad digital que ese sea el caso. El valor de confianza puede ser una métrica fácilmente interpretable, tal como un valor entre 0 y 1 (o 0 % y 100 %), 0(%) que representa incertidumbre completa y 1(00 %) que representa certeza total, aunque esto último es poco probable en la práctica. El valor de confianza puede cambiar con el tiempo. Por ejemplo, a medida que el usuario carga más ítems de datos, por ejemplo fotos de su cara (“selfies”) que, en algunas realizaciones, pueden ser necesarias para iniciar sesión en el sistema de identidad digital y ser almacenadas en el sistema de identidad digital cada vez, esto puede ejercer una influencia positiva en el valor de confianza, al hacer que aumente (al menos en ausencia de otras influencias), siempre que las fotos coincidan (mientras que las fotos para las que la coincidencia es cuestionable pueden tener el efecto contrario). De manera similar, a medida que la entidad completa una transacción adicional, esto puede ejercer una influencia positiva similar. Por el contrario, cuando el(los) ítem(s) de datos en el perfil digital se capturan de, por ejemplo, un documento de identificación del mundo real, a medida que el documento envejece, esto puede ejercer una influencia negativa en el valor de confianza, lo que hace que disminuya (al menos en ausencia de otras influencias). Muchas de estas influencias se pueden agregar, por lo que el valor de confianza refleja una confianza general.

En otro aspecto, un sistema de identidad digital comprende: un módulo de inscripción configurado para recibir un ítem de datos desde un dispositivo de inscripción y para crear en el almacenamiento electrónico persistente un perfil digital que comprende el ítem de datos; un módulo de creación de credenciales configurado para generar una credencial a partir de una secuencia aleatoria, para asociar la credencial con el perfil digital en una base de datos y para transmitir la credencial al dispositivo de inscripción; un módulo de publicación configurado, en respuesta a la presentación posterior de la credencial al sistema de identidad digital, para publicar el perfil digital al almacenar una versión del perfil digital en una ubicación de memoria accesible para un dispositivo que presente la credencial.

Una entidad (que puede ser un usuario del dispositivo de inscripción o el propio dispositivo de inscripción) puede proporcionar su credencial a una entidad presentadora (por ejemplo, el dispositivo presentador o el usuario del mismo) como una forma de confirmar su identidad, como se incorpora en el perfil, a la entidad presentadora. Es decir, la credencial y el perfil digital se pueden utilizar como un sustituto de un documento de identidad del mundo real.

El enlace se genera a partir de una secuencia aleatoria y/o la ubicación de la memoria direccionable se selecciona en base a una secuencia aleatoria. La generación aleatoria de enlaces/selección de direcciones de memoria garantiza un uso eficiente de la dirección de memoria/espacio de enlace.

El ítem de datos puede ser, por ejemplo, una imagen visual de la entidad. En el caso de una entidad humana, puede ser una foto de su cara capturada a partir de, o que se sabe coincide con, una fotografía de identificación de un documento de identificación del mundo real tal como un pasaporte o una licencia de conducción. Esto se puede capturar utilizando una cámara y/o tecnología inalámbrica (NFC, Bluetooth, etc.) si un chip electrónico adecuado está integrado en el documento. La otra entidad puede verificar que el usuario es quien dice ser al comparar visualmente la cara real del usuario con la del perfil publicado. También se pueden recibir y almacenar en el perfil otros ítems de datos como el nombre del usuario, datos de nacimiento, nacionalidad, etc. del documento de identidad. Se pueden crear múltiples perfiles para un usuario, que pueden ser únicos, pero que no obstante comparten algunos ítems de datos. Por ejemplo, un perfil básico puede tener solo un ítem de datos (por ejemplo, una foto), y el(los) perfil(es) adicionales pueden tener la foto más diversos grados de datos de usuario adicionales (nombre, nombre y fecha de nacimiento, nombre y fecha de nacimiento y nacionalidad, etc.).

Preferiblemente, los metadatos disponibles para un dispositivo informático que envía el mensaje electrónico se incluyen en el mensaje. Los metadatos pueden ser metadatos del propio dispositivo, por ejemplo, un identificador de dispositivo (ID), tal como un número de serie o una dirección MAC del dispositivo, o pueden ser metadatos relacionados, tales como datos de (geo)localización (por ejemplo, GPS) que identifican una (geo)localización del dispositivo cuando se envió el mensaje. Los metadatos se pueden utilizar para generar la credencial, por ejemplo, como un hash de los metadatos y una secuencia aleatoria (semilla). Esto puede dar lugar a que una credencial tenga un tamaño de bits grande, por lo que se produce un ahorro significativo de memoria al almacenar los “ ingredientes” utilizados para crear la credencial en el sistema de identidad digital en lugar de la credencial en sí misma. A continuación, se puede crear una copia de la credencial cuando sea necesario, por ejemplo para determinar si una credencial presentada al sistema coincide con la original (el acceso al perfil publicado solo se puede conceder si este es el caso). La semilla y los metadatos pueden ser aplicados a un hash un número aleatorio de veces, y los ingredientes almacenados entonces también incluyen este número aleatorio.

Cuando los metadatos comprenden un ID de dispositivo para el perfil, solo se puede conceder si la credencial se presenta junto con un ID de dispositivo coincidente. Por lo tanto, el uso de la credencial está restringido a ese dispositivo para mayor seguridad (si el usuario desea utilizar múltiples dispositivos para confirmar su identidad, entonces puede solicitar una credencial independiente para cada dispositivo, cada credencial unida al perfil).

En otro aspecto, un método para proporcionar acceso a un perfil digital comprende recibir una credencial de un solo uso asociada con un perfil digital en el almacenamiento electrónico persistente; validar la credencial y, solo si la credencial es válida, publicar el perfil en una ubicación de memoria direccionable al almacenar una versión de la misma en la ubicación de memoria, invalidando de este modo la credencial; generar una nueva credencial de un solo uso para el perfil digital; asociar la nueva credencial con el perfil digital; y transmitir la credencial nueva a una dirección asociada con una entidad, mediante la cual la entidad puede utilizar la credencial nueva una vez a partir de entonces para hacer que el perfil se vuelva a publicar en una ubicación de memoria direccionable diferente.

De acuerdo con este otro aspecto, cada vez que se presenta una credencial actual, se publica una nueva versión del perfil y se crea una nueva credencial.

El perfil también puede tener un valor de confianza asignado, que es indicativo de la confianza que tiene el sistema en que la entidad tiene realmente la identidad que está confirmando. El valor de confianza está disponible preferiblemente con el perfil publicado, por ejemplo, se puede incluir y publicar con el propio perfil en la misma ubicación de memoria. Por lo tanto, al validador no se le indica simplemente que la entidad es quien o lo que dice ser, sino que también se le informa cuán confiable considera el sistema de identidad digital que ese sea el caso. El valor de confianza puede ser una métrica fácilmente interpretable, tal como un valor entre 0 y 1 (o 0 % y 100 %), 0(%) que representa incertidumbre completa y 1(00 %) que representa certeza total, aunque esto último es poco probable en la práctica. El valor de confianza puede cambiar con el tiempo. Por ejemplo, a medida que el usuario carga más ítems de datos, por ejemplo fotos de su cara (“selfies”) que, en algunas realizaciones, pueden ser necesarias para iniciar sesión en el sistema de identidad digital y ser almacenadas en el sistema de identidad digital cada vez, esto puede ejercer una influencia positiva en el valor de confianza, al hacer que aumente (al menos en ausencia de otras influencias), siempre que las fotos coincidan (mientras que las fotos para las que la coincidencia es cuestionable pueden tener el efecto contrario). De manera similar, a medida que la entidad completa una transacción adicional, esto puede ejercer una influencia positiva similar. Por el contrario, cuando el(los) ítem(s) de datos en el perfil digital se capturan de, por ejemplo, un documento de identificación del mundo real, a medida que el documento envejece, esto puede ejercer una influencia negativa en el valor de confianza, lo que hace que disminuya (al menos en ausencia de otras influencias). Muchas de dichas influencias se pueden agregar, por lo que el valor de confianza refleja una confianza general.

De acuerdo con varios aspectos de la presente invención, se confirma una identidad utilizando un perfil digital. Por ejemplo, se puede crear un perfil a partir de datos capturados de un documento de identidad del mundo real tal como un pasaporte o una licencia de conducción, que preferiblemente comprende una fotografía de identificación del documento. Una vez creado, la entidad puede utilizar el perfil para confirmar su identidad a una entidad presentadora (validador). La entidad puede proporcionar la credencial a la entidad presentadora que la presenta a un sistema informático de identidad digital. No solo el perfil se pone a disposición del validador, sino que también se presenta un valor de confianza asociado con el perfil.

De acuerdo con otro aspecto, un sistema informático comprende: almacenamiento electrónico; una interfaz de red configurada para recibir mensajes electrónicos; y un procesador configurado para ejecutar código de gestión de identidades que opera para:

recibir un mensaje electrónico de la interfaz de red, el mensaje que incluya al menos un ítem de datos que se incluirá en un perfil digital para una entidad, el ítem de datos asociado con la entidad y que identifica de manera única a la entidad;

extraer el ítem de datos del mensaje electrónico;

crear un perfil digital utilizando el ítem de datos en el almacenamiento electrónico, en el que el perfil comprende el ítem de datos;

asignar un valor de confianza al perfil, en el que el valor de confianza se asigna en base a al menos una de las fuentes del mensaje electrónico y un tipo de ítem de datos; y

crear y transmitir una credencial a la entidad, en la que la presentación de la credencial al sistema informático hace que una versión del perfil digital y el valor de confianza estén disponibles para una entidad presentadora.

El valor de confianza es indicativo de la confianza que tiene el sistema en que la entidad, por ejemplo, un humano o un dispositivo, tiene realmente la identidad que están confirmando. Por lo tanto, al validador no se le indica simplemente que la entidad es quien o lo que dice ser, sino que también se le informa cuán confiable considera el sistema de identidad digital que ese sea el caso. El valor de confianza puede ser una métrica fácilmente interpretable, tal como un valor entre 0 y 1 (o 0 % y 100 %), 0(%) que representa incertidumbre completa y 1(00 %) que representa certeza total, aunque esto último es poco probable en la práctica.

El ítem de datos puede ser una imagen visual de la entidad, que puede ser un usuario. Por ejemplo, se pueden incluir dos imágenes visuales del usuario en el mensaje: la primera una foto de identificación capturada de un documento de identidad del mundo real; la segunda, una foto de la cara del usuario que se ha tomado con una cámara (“selfie”). El reconocimiento facial se puede utilizar para determinar qué tan cerca en coincidencia están los dos ítems de datos y el valor de confianza asignado en base a la comparación para reflejar esto. De este modo, se indica a la entidad presentadora hasta qué punto las caras del usuario coinciden con cualquier forma de documento de identidad que haya utilizado para crear el perfil.

El valor de confianza puede cambiar con el tiempo. Por ejemplo, a medida que el usuario carga más ítems de datos, por ejemplo, selfies, que en algunas realizaciones pueden ser necesarios para iniciar sesión en el sistema de identidad digital y almacenados en el sistema de identidad digital cada vez, esto puede confirmar una influencia positiva en el valor de confianza, lo que hace que aumente (al menos en ausencia de otras influencias), siempre que las fotos coincidan (mientras que las fotos para las que la coincidencia es cuestionable pueden tener el efecto contrario). De manera similar, a medida que la entidad completa una transacción adicional, esto puede ejercer una influencia positiva similar. Por el contrario, cuando el(los) ítem(s) de datos en el perfil digital se capturan de, por ejemplo, un documento de identificación del mundo real, a medida que el documento envejece, esto puede influir negativamente en el valor de confianza, lo que hace que disminuya (al menos en ausencia de otras influencias). Muchas de dichas influencias se pueden agregar, por lo que el valor de confianza refleja una confianza general.

Se proporcionan los métodos correspondientes, que se implementan por ordenador. También se proporciona un producto de programa informático que comprende código almacenado en un medio de almacenamiento legible por ordenador configurado para implementar cualquier método o sistema divulgado en el presente documento.

Es posible que se publique una versión del perfil para que esté disponible. Al publicar una versión del perfil en lugar de permitir el acceso directo al perfil, se preserva la seguridad del perfil ya que el perfil subyacente nunca es visible fuera del sistema de identidad digital.

El ítem de datos puede ser, por ejemplo, una imagen visual de la entidad. En el caso de una entidad humana, puede ser una foto de su cara capturada a partir de, o que se sabe coincide con, una fotografía de identificación de un documento de identificación del mundo real tal como un pasaporte o una licencia de conducción,. Esto se puede capturar utilizando una cámara y/o tecnología inalámbrica (NFC, Bluetooth, etc.) si un chip electrónico adecuado está integrado en el documento. La otra entidad puede verificar que el usuario es quien dice ser al comparar visualmente la cara real del usuario con la del perfil publicado. También se pueden recibir y almacenar en el perfil otros ítems de datos como el nombre del usuario, datos de nacimiento, nacionalidad, etc. del documento de identidad. Se pueden crear múltiples perfiles para un usuario, que pueden ser únicos, pero que no obstante comparten algunos ítems de datos. Por ejemplo, un perfil básico puede tener solo un ítem de datos (por ejemplo, una foto), y el(los) perfil(es) adicionales pueden tener la foto más diversos grados de datos de usuario adicionales (nombre, nombre y fecha de nacimiento, nombre y fecha de nacimiento y nacionalidad, etc.).

Preferiblemente, los metadatos disponibles para un dispositivo informático que envía el mensaje electrónico se incluyen en el mensaje. Los metadatos pueden ser metadatos del propio dispositivo, por ejemplo, un identificador de dispositivo (ID), tal como un número de serie o una dirección MAC del dispositivo, o pueden ser metadatos relacionados, tales como datos de (geo)localización (por ejemplo, GPS) que identifican una (geo)localización del dispositivo cuando se envió el mensaje. Los metadatos se pueden utilizar para generar la credencial, por ejemplo, como un hash de los metadatos y una secuencia aleatoria (semilla). Esto puede dar lugar a que una credencial tenga un tamaño de bits grande, por lo que se produce un ahorro significativo de memoria al almacenar los “ ingredientes” utilizados para crear la credencial en el sistema de identidad digital en lugar de la credencial en sí misma. A continuación, se puede crear una copia de la credencial y cuando sea necesario, por ejemplo para determinar si una credencial presentada al sistema coincide con la original (el acceso al perfil publicado solo se puede conceder si este es el caso). La semilla y los metadatos pueden ser aplicados a un hash un número aleatorio de veces, y los ingredientes almacenados también incluyen este número aleatorio.

A efectos de auditoría, se puede generar un recibo maestro que comprenda datos de cada recibo en las realizaciones y almacenarlo en un libro de recibos maestro en el sistema de identidad digital. Es decir, tanto el primero como el recibo maestro se pueden almacenar por separado en el sistema de identidad digital. El recibo maestro puede comprender solo parte del primer recibo, por ejemplo el enlace y el identificador de transacción, pero no la credencial.

También se proporciona un producto de programa informático que comprende código almacenado en un medio de almacenamiento legible por ordenador configurado para implementar cualquier método o sistema divulgado en el presente documento.

Para una mejor comprensión de la presente invención y para mostrar cómo se puede llevar a cabo la misma, se hará ahora referencia a modo de ejemplo a los dibujos acompañantes en los que:

La Figura 1 es un diagrama esquemático de los elementos centrales de un sistema de identidad digital;

La Figura 1a es un diagrama de bloques esquemático de los componentes principales de un sistema de identidad digital;

La Figura 2 es un diagrama esquemático expandido de los componentes funcionales de un sistema de identidad digital; La Figura 3a es un diagrama de bloques esquemático de ítems de datos almacenados como parte de un sistema de identidad digital;

La Figura 3b es un diagrama de bloques de una estructura de base de datos para un sistema de identidad digital; La Figura 3c muestra un libro de recibos maestro de un sistema de identidad digital;

La Figura 4a es un diagrama de flujo esquemático que ilustra la creación de credenciales en un sistema de identidad digital;

La Figura 4b es un diagrama de flujo que muestra el flujo realizado en un teléfono inteligente y servicio de registro de la creación de credenciales en un sistema de identidad digital;

La Figura 5 ilustra la información estandarizada de los pasaportes;

La Figura 6 es un diagrama de flujo esquemático que muestra un proceso de autenticación;

La figura 6a es un diagrama de flujo para un proceso de autenticación;

La Figura 6b muestra los detalles de los recibos generados durante un proceso de autenticación;

La Figura 6c muestra los detalles de un recibo maestro generado durante un proceso de autenticación;

La Figura 6d ilustra esquemáticamente ciertas relaciones entre varios recibos y recibos maestros que surgen debido a su contenido;

La Figura 7 es un diagrama de flujo esquemático que muestra un proceso de autenticación para un servicio web; Las Figuras 8a (diagrama de flujo) y 8b (diagrama de señalización) describen una situación en la que una persona registrada en un sistema de identidad digital desea que un tercero le asigne un perfil;

Las Figuras 9a (diagrama de flujo) y 9b (diagrama de señalización) muestran un caso en el que una persona no registrada en un sistema de identidad digital desea que un tercero le asigne un perfil;

La Figura 10 muestra un diagrama de bloques de un dispositivo de usuario;

La Figura 11A ejemplifica cómo se puede crear una identidad digital;

Las Figuras 11B a 11H ejemplifican casos de uso de un perfil digital;

La Figura 12 muestra una transacción de uPass realizada entre tres entidades; y

La Figura 13 muestra una transacción alternativa de uPass realizada entre tres entidades.

Descripción de las realizaciones preferidas

La siguiente descripción divulga un sistema de registro y autenticación de identidad denominado sistema de uPass. Como premisa básica, un usuario del sistema de uPass puede cargar y registrar copias de sus documentos de identidad y, a cambio, recibe un ID digital anclado que se puede utilizar para verificar su identidad a terceros sin necesidad de presentar estos documentos de identidad. También pueden especificar la naturaleza y la cantidad de información personal que estará disponible al hacer esto.

Se supone que los casos de uso en los que se va a registrar o verificar una identidad están fuertemente asociados con el uso de dispositivos móviles tales como teléfonos inteligentes y ordenadores tipo tableta, aunque la invención no se limita a estos dispositivos. Además, se describe el registro que se basa en documentos de identidad que están diseñados para ser escaneados electrónicamente, ya sea con texto compatible con OCR o con chips integrados compatibles con NFC, a modo de ejemplo no limitante. Será evidente a partir de lo siguiente que se puede utilizar cualquier tipo de ítems de datos relacionados con la identidad e introducir en el sistema de cualquier manera adecuada. La Figura 1a es un diagrama de bloques esquemático de los principales componentes de un sistema de identidad digital.

Un servicio central (uPass) 14 almacena las credenciales de forma segura y gestiona las validaciones. El servicio central se puede implementar de cualquier manera adecuada y requiere al menos un procesador 114 que ejecute el código de gestión de identidades y componentes de almacenamiento electrónico que proporcionen un almacenamiento seguro. Puede haber varios procesadores en una red de microprocesamiento distribuida, o una unidad central de procesamiento en uno o múltiples servidores. Los componentes de almacenamiento electrónico pueden tomar cualquier forma y pueden ser memoria local o remota. Como será evidente, el almacenamiento electrónico proporciona tanto un almacenamiento seguro como un almacenamiento escribible de acceso aleatorio 35.

Se proporciona una primera aplicación móvil 22 para alojar en un dispositivo móvil 12. La primera aplicación móvil es para escanear ítems de datos de un documento de identidad y transmitirlos al servicio central 14.

También se proporciona una segunda aplicación móvil 50 para ejecución por un dispositivo móvil 12, la segunda aplicación móvil para solicitar una validación de credenciales contra el servicio de almacenamiento 14. Se apreciará que no todos los dispositivos móviles tienen necesariamente ambas aplicaciones 22 y 50. Por ejemplo, algunos dispositivos móviles se pueden equipar sólo para escanear ítems de datos y transmitirlos al servicio central 14, mientras que otros dispositivos pueden ser capaces sólo de realizar la validación de credenciales. Sin embargo, es probable que la mayoría de los dispositivos móviles asociados con los usuarios de uPass tengan ambas aplicaciones cargadas. Las aplicaciones móviles (Apps) se pueden descargar desde un servidor de UPass.

Se proporciona una arquitectura segura para la comunicación entre los componentes del sistema. Esto garantiza que se mantenga la privacidad, en particular cuando se consideran las comunicaciones entre los dispositivos móviles 12 asociados a los usuarios de uPass y el servicio central 14.

Se proporciona un marco de confianza 69 para evaluar el grado de confianza que se puede colocar en un perfil de identidad registrado en el servicio central 14. Se proporciona un mecanismo automatizado 67 para realizar un arbitraje de fiabilidad oportuno entre usuarios a través de credenciales ofrecidas (por ejemplo, códigos QR). A continuación, se describirá con más detalle cada componente del sistema.

La Figura 1 muestra los elementos básicos de un sistema de identidad en forma muy esquemática. Hay dos flujos de trabajo básicos, uno relacionado con el registro de documentos de identidad del usuario y el otro con la verificación de la identidad (autenticación).

Un pasaporte electrónico 10 u otro documento de identidad (por ejemplo, una licencia de conducción) es leído por un dispositivo móvil 12 (por ejemplo, a través de NFC) y los datos de registro se transmiten al servicio de uPass 14 de forma segura a través de Internet, como se describe más adelante. El servicio de uPass almacena el registro de datos en uno o más perfiles que forman parte de una identidad digital 28.

Hay tres elementos en un dispositivo móvil que se pueden utilizar para el almacenamiento; una tarjeta SD 12a o una tienda extraíble similar; la tarjeta SIM 12b y, en algunos dispositivos, un espacio de almacenamiento interno seguro 12c. Dicho elemento de almacenamiento se puede utilizar para almacenar una credencial 30 (por ejemplo, un código QR) generada por el sistema de uPass a partir de un perfil digital y devuelta al dispositivo móvil 12.

El servicio de uPass 14 es proporcionado por un sistema informático con puntos de acceso separados (14a, 14b) para el registro y la verificación. La partición del flujo de trabajo de esta manera proporciona la confianza de que un error en el punto de acceso de registro no pondrá necesariamente en peligro el punto de acceso de verificación y viceversa. Los puntos de acceso pueden ser ordenadores físicamente separados que se pueden comunicar a través de una red, o dominios virtualmente separados en la misma ubicación física.

La Figura 10 muestra un diagrama de bloques de un dispositivo de usuario 12 (por ejemplo, un dispositivo inteligente tal como un teléfono inteligente o un ordenador tipo tableta). El dispositivo de usuario comprende un procesador 1104 que ejecuta el software de identidad digital 1006, por ejemplo, en la forma de aplicación o “app” (aplicación de uPass/aplicación de verificación), y al que está conectada una cámara 1108, una interfaz inalámbrica (por ejemplo, NFC, Bluetooth) 1010 y una pantalla 1002 para emitir información visual a un usuario del dispositivo 12.

Cualificación para una actividad restringida

Uno de los usos más comunes del ID con foto es confirmar que una persona cumple con la edad mínima legal para una actividad particular que desea realizar, tal como ingresar a un club nocturno o comprar alcohol. El sistema de uPass es particularmente adecuado para este propósito, ya que una aplicación de verificación de cliente 50 (véase Figura 1a) que se ejecuta en un teléfono inteligente u ordenador tipo tableta se puede adaptar tanto para responder a la pregunta subyacente “¿esta persona tiene la edad suficiente?” como para proporcionar una confirmación con foto de que la persona que presenta las credenciales es de hecho la persona a la que pertenecen estas credenciales. En la siguiente descripción, la atención se centra en la precisión de una foto.

Más adelante se discute una serie de casos de uso. Un ejemplo de caso de uso es el de un festival de música que opta por ofrecer entrada sin boleto a través de uPass. En este escenario, un asistente (portador) ofrece su credencial (la credencial 30 que recibió del proceso de registro) en su dispositivo móvil y el operador del lugar (validador) la compara contra el punto de acceso de verificación del servicio de uPass 14 para confirmar que se puede conceder la entrada.

Hay varias maneras en las que se podría presentar la credencial: un blob binario transferido por NFC; un código de barras para escanear; una dirección de correo electrónico; o bien algún tipo de código QR.

Conexión uPass

Otro caso de uso de interés es el de autenticar el inicio de sesión en un sistema remoto a través de un dispositivo local que puede carecer de una aplicación de uPass, eliminando la necesidad de recordar nombres de usuario o contraseñas siempre que esté disponible un dispositivo de uPass (tal como el dispositivo móvil 12). En este escenario, un dispositivo de validación asociado a un uPass escanea un código QR que se muestra en el formulario de inicio de sesión transmitido desde el sistema remoto al dispositivo local y lo utiliza para establecer un sistema de usuario. Esta técnica se puede utilizar para establecer que el propietario del dispositivo de uPass tiene permiso para iniciar sesión, pero también puede permitir que el propietario esté seguro de que cualquier contenido que reciba del sistema remoto proviene de una fuente válida.

La Figura 2 es un diagrama de bloques esquemático de la arquitectura de un sistema de uPass como bloques funcionales, que ilustra los flujos de trabajo en el sistema.

Un registrante 20 utiliza una aplicación 22 en su teléfono inteligente u ordenador tipo tableta 12 para capturar detalles de su pasaporte 10 (por ejemplo, a través de NFC y/o cámara) y la combina con una foto 18 de sí mismo (una “selfie”) capturada con el mismo dispositivo para producir un mensaje de registro electrónico 23. Esto se envía de forma segura al punto de acceso de registro 14a del sistema de uPass 14 que realiza el procesamiento necesario (reconocimiento facial/OCR) para extraer datos relevantes y crear una cuenta para el registrante, como se describe más adelante. Una vez finalizado con éxito, se devuelve un mensaje de confirmación a su dispositivo junto con un token de autenticación (credencial) que crea un enlace al nuevo perfil de identidad uPass “publicado”.

Fiabilidad contingente

Una característica del sistema de uPass es que se proporciona una foto como parte del perfil “publicado” vinculado a la credencial. Sin embargo, la visualización de una fotografía cuando se presenta una credencial de uPass en un proceso de verificación solo confirma que la identidad declarada del usuario registrado coincide con la de la persona que registró el uPass en primer lugar, no que la identidad registrada sea en sí misma un registro válido y fiable de la identidad del registrante.

Para abordar esto, una realización de la invención introduce el concepto de fiabilidad contingente, por el cual el perfil de identidad del usuario tiene un valor de confianza de perfil asociado “CV1” n para 2,3,4 en base a la calidad y la fuente de los documentos de identidad asociados con él, y su uso histórico. La forma en que esto funciona en la práctica es que se permiten múltiples fuentes de datos de identidad y a cada una se le asigna un nivel de fiabilidad. A continuación, las respuestas se pueden calificar cuando lo exija la ley.

Con el fin de explicar la fiabilidad contingente, a continuación, se supone que el documento de identidad que se va a procesares un pasaporte electrónico con la opción de una interacción NFC, un escaneo de calidad OCR o ambos. En la práctica, la identidad digital se basa en ítems de datos de información primarios tales como el nombre, edad, nacionalidad y fotografía, para minimizar los problemas de compatibilidad.

La jerarquía de fiabilidad contingente identifica cinco niveles naturales de confianza en base a la manera en que los datos de registro ingresan al sistema:

• presentado en persona a un agente de fiabilidad que confirma que coincide con la parte presentadora;

• una aplicación móvil fiable con medidas de seguridad adicionales;

• un sitio web fiable;

• presentado a través de correo certificado;

• Sin documentos de registro

El primer caso establece un nivel máximo de confianza para la fiabilidad contingente. El valor exacto asignado se puede determinar mediante un análisis estadístico de los riesgos involucrados, pero como regla general no debe ser superior al 95 por ciento (ningún dato debe considerarse incontrovertible). El número exacto puede variar dependiendo del agente de fiabilidad en cuestión.

Un uPass se puede convertir en fiable como resultado de la verificación manual de esta manera. Por lo tanto, la “fiabilidad” es solo un valor fijo en base a el registro inicial, pero puede variar como un conjunto de proposiciones con respecto al proceso de registro para cada uno de los múltiples documentos de anclaje.

Se pueden aplicar comprobaciones adicionales para mejorar la posición (valor de confianza) de un uPass, tal como:

• avales por los usuarios existentes de uPass;

• lecturas de datos NFC en un entorno fiable;

• solicitud aleatoria de presentación de documentos a un agente fiable

• contacto directo aleatorio a través de una videollamada para confirmar que el registrante de uPass aún tiene documentos de registro

La confianza de la verificación facial cambia con el tiempo. Cuando los usuarios se registran, lo hacen con su cara y un pasaporte. En este momento, puede haber una confianza muy baja de que son quienes dicen ser (aunque esto depende de cualquier documento(s) de anclaje que proporcionen). A partir de entonces, los datos de la imagen se capturan con cada inicio de sesión facial. Cada vez que se captura otra selfie, se agrega a una base de datos de imágenes. Estas selfies se combinan en un solo Registro de Identificación Facial. La clave en el presente documento es que se capturan a lo largo del tiempo en una variedad de condiciones de iluminación diferentes (porque se capturan en un teléfono u otro dispositivo inteligente) - y cuando se combinan proporcionan resultados más precisos. En las realizaciones, el registro facial actual (que podría estar compuesto por un número de selfies más recientes, por ejemplo, un número pequeño tal como 5) con la foto de pasaporte original capturada al registrarse. Tenga en cuenta que, en lugar de datos de imágenes faciales completas, se pueden extraer datos de imagen, como un patrón binario local (LBP) o una plantilla facial.

Cuando se utiliza un documento de anclaje fiable tal como un pasaporte, al registrarse, el valor de confianza es razonablemente alto, pero aún puede crecer con el tiempo de esta manera.

La confianza de todo el sistema también crece con el tiempo, debido a otros factores tales como la verificación entre pares. Una característica importante del sistema actual radica en la siguiente combinación de anclajes fiables:

a) teléfono;

b) selfie;

d) validación por pares

Un valor de confianza dado se representa como una variable de punto fijo, a la que se asigna un valor (variable) entre por ejemplo 0 y 1 (0 % y 100 %).

Perfiles de usuario y privacidad

Un registrante proporciona ítems de datos de identificación personal para permitir que una credencial de uPass confirme su identidad en una fecha posterior. Por su propia naturaleza, estos datos de identificación son confidenciales y el sistema de uPass proporciona medios por los cuales pueden ser manejados con el nivel de privacidad que un usuario de uPass considere apropiado para las circunstancias en las que se está utilizando. Para facilitar esto, un uPass (identidad digital) individual tiene una serie de perfiles asociados.

A continuación, se hará referencia a la Figura 3a para explicar la naturaleza de un “uPass” o, en otras palabras, una identidad digital que se crea para un usuario y que se puede verificar. La Figura 3a muestra esquemáticamente los componentes que componen un uPass para una persona 20. Estos componentes se almacenan en un almacenamiento electrónico de un tipo adecuado en el sistema de uPass. Por ejemplo, cada usuario 20 puede estar asociado con una base de datos o parte de una base de datos adjunta a un identificador único 26 que identifica los componentes del uPass para esa persona. Por ejemplo, el almacenamiento electrónico puede adoptar la forma de un almacén seguro, como se indica en el número de referencia 24 en la Figura 2. Por lo tanto, cada persona 20 está asociada con un identificador único 26 que se asocia con todos los componentes del uPass para el usuario 20. La identidad digital comprende un conjunto de perfiles digitales 28a, 28b, 28c, 28d. Cada perfil comprende uno o más pares de clave valor, donde la clave identifica la naturaleza de un ítem de datos que se almacena en el perfil y el valor identifica el propio ítem de datos. Por ejemplo, la clave puede ser “foto” y el valor sería una fotografía del usuario. De hecho, el valor puede ser una dirección en la que se almacena una fotografía como un componente separado del uPass (véase 18, 18'). Aunque se muestran esquemáticamente como bloques individuales, los perfiles se pueden construir a partir de listas vinculadas de pares clave/valor y valores de confianza, con cada ítem de una lista apuntando a su antecesor. Cada vez que se “publica” un perfil (descrito más adelante), se crea un nuevo “encabezado” de la lista, que incorpora las modificaciones que surgen del uso del perfil.

Otro componente del uPass son el uno o más documentos de anclaje que se han utilizado para proporcionar ítems de datos para los perfiles. Un ejemplo de documento de anclaje es el pasaporte 10. Se pueden almacenar múltiples documentos de anclaje diferentes.

Como se mencionó anteriormente, una vez que el registro se realiza con éxito, se envía un mensaje de confirmación 25 desde el servicio de registro a la aplicación en el teléfono inteligente que incluye una credencial. Cada vez que se agrega un ítem de datos a un perfil, o se utiliza un perfil de uPass, se crea una nueva credencial para ese perfil y se transmite al propietario del perfil. Estas credenciales se almacenan en asociación con el identificador 26 en el uPass para la persona 20 y están unidas a un perfil. Una nueva credencial es una modificación que surge de la “publicación” de un perfil... Como las credenciales se utilizan para “desbloquear” los perfiles, se muestran como claves 30. En la práctica, cada credencial es una cadena digital aleatoria única que se introduce en una base de datos, que se describe más adelante con referencia a la Figura 3b.

Cada usuario 20 se asocia con uno o más dispositivos inteligentes (tales como un teléfono inteligente o un ordenador tipo tableta), mostrados como 12 y 12a. Los metadatos sobre estos dispositivos se almacenan como parte del uPass para el usuario. Cada vez que se realiza una transacción utilizando un uPass, se emite un par de recibos. Esto se describirá con más detalle más adelante, pero baste decir que una pista de auditoría de recibos se almacena en un libro de recibos local 31e como parte del uPass de un usuario. Estos recibos se ilustran esquemáticamente con el número de referencia 32e. Cada dispositivo inscrito 12a, 12b tiene su propio libro de recibos local en el dispositivo o en un servidor remoto al que puede acceder el dispositivo.

Un libro de recibos maestro global 32 (figura 3C) contiene recibos maestros 31, que se relacionan con los recibos 32e (individuales) de la manera que se describe a continuación. Los recibos individuales emitidos a una entidad que es portador o validador se marcan como 32v y 32e en el presente documento, respectivamente.

Como parte del procedimiento de autenticación que se describirá más adelante, cuando se presente una credencial válida al sistema de uPass 14, se publicará un perfil de acuerdo con la naturaleza de la credencial que se presente. Estos perfiles publicados se muestran bajo el número de referencia 34 y se ilustran esquemáticamente con cerraduras que representan que se puede utilizar una clave correspondiente a una credencial para desbloquear estos perfiles para publicación. Un perfil se publica al ser accesible en una ubicación de almacenamiento direccionable en una memoria 35 (por ejemplo, una caché) que tiene una dirección unida a la credencial.

Una credencial generada se puede almacenar en el sistema de uPass, lo cual es apropiado si es completamente aleatorio. La credencial almacenada se compara contra una credencial presentada y el perfil al que está unida la credencial se desbloquea solo si la credencial almacenada coincide con la credencial presentada. Sin embargo, cuando la credencial se genera utilizando ciertos “ ingredientes” (tal como una secuencia aleatoria, un número aleatorio y metadatos del dispositivo, tal como un identificador de dispositivo), generalmente es más eficiente almacenar los ingredientes en su lugar, ya que generalmente tienen un tamaño de bits menor que la propia credencial. Los ingredientes se pueden utilizar para generar una copia de la credencial para dicha comparación. Por ejemplo, la credencial se puede generar mediante el hash de una semilla aleatoria y los metadatos del dispositivo (por ejemplo, cuál es o comprende un identificador de dispositivo) un número aleatorio de veces - el sistema de uPass puede almacenar los metadatos, la semilla y el número aleatorio para crear otra copia más adelante.

En el momento del registro se crean tres (o cuatro) perfiles predeterminados:

• un perfil anónimo 28a que afirma la unicidad de la identidad y presenta una foto para su inspección visual;

• un perfil de ID con foto 28b que también presenta el nombre tal como se enumera en el documento de registro;

• un perfil mayoritario 28c que agrega la fecha de nacimiento al ID con foto;

• (y un cuarto opcional) un perfil de nacionalidad 28d que agrega la nacionalidad al ID con foto

Se pueden crear perfiles adicionales para el usuario que le permitan agregar información personal adicional o presentar su información personal de diferentes maneras. Estos perfiles se pueden adjuntar a ellos por cualquier otro usuario como resultado de una transacción de uPass válida. Una aplicación de solicitud de perfil se utiliza para permitir que un usuario de uPass haga que otro usuario publique un perfil en su nombre. Nadie puede crear un perfil en su propio nombre. A este respecto, tenga en cuenta que el sistema de uPass comprende un controlador 116 que actúa como un tercero para emitir uPasses basados en documentos de anclaje.

Cuando se ingresa nueva información personal en un perfil sin el respaldo de un documento de registro, ese perfil recibe el nivel más bajo de fiabilidad contingente. Por ejemplo, un tercero podría ser un empleador que ingresa ítems de datos en una solicitud de solicitud de perfil para un empleado. Se crea una credencial para el empleado en base a la información proporcionada por el empleador, la credencial se une al perfil y se proporciona al empleado. Para mejorar el nivel de fiabilidad contingente, el sistema permite que el usuario de uPass tenga el perfil validado por otros usuarios de uPass, creando una red de confianza que puede ser inspeccionada. Esto ocurre cada vez que el propietario de un uPass utiliza su credencial en un procedimiento de validación. La red de confianza para cada perfil es un gráfico social en el que cada nodo representa un anclaje de confianza. Estos se discutirán más adelante. El nivel de fiabilidad contingente depositado en el documento estará en función del número y la calidad de las validaciones que reciba el perfil.

Se hace referencia a las Figuras 8a y 8b para describir una situación en la que una persona desea que un tercero le asigne un perfil. En el ejemplo particular que se da, la persona es un nuevo empleado, y el tercero es su empleador. El nuevo empleado desea que el empleador le asigne un perfil. Sin embargo, hay muchas otras situaciones en las que una persona puede desear que un tercero le asigne un perfil. En las circunstancias de las Figuras 8a y 8b, se supone que tanto el nuevo empleado NE como el empleador E ya están registrados en el sistema de uPass y tienen credenciales activas. En la Etapa S80, el nuevo empleado proporciona su credencial 30 NE al empleador. En la Figura 8b, el nuevo dispositivo del empleado está etiquetado como 12NE y el dispositivo del empleador está marcado como 12E. En la Etapa S82, el empleador envía la nueva credencial de empleado 30NE y su propia credencial 30E al servicio de registro de uPass 14. Además, el empleador envía en dicho mensaje un perfil que ha creado para el nuevo empleado. El servicio de uPass verifica que las credenciales del nuevo empleado y empleador sean válidas y, de ser así, crea un perfil para el nuevo empleado en base a la información proporcionada por el empleador y encuentra una nueva credencial 30”NE para ese perfil. A continuación, esa nueva credencial se envía (Etapa S84) al nuevo dispositivo del empleado. El servicio de uPass 14 también envía una credencial de reemplazo 30”E al dispositivo del empleador, ya que el empleador ha agotado su credencial válida de un solo uso cuando trató de asignar un perfil para el nuevo empleado.

A continuación, el perfil se almacena en el sistema de uPass (Etapa S88). Se apreciará que, aunque se muestran en secuencia, las etapas S84, S86 y S88 se pueden llevar a cabo en cualquier orden o en paralelo.

Las Figuras 9a y 9b muestran el caso en el que el nuevo empleado aún no está registrado en el sistema de uPass. En este caso, en la Etapa S90 el nuevo empleado hace una solicitud del “mundo real” al empleador “¿Puedo tener un uPass?” Esto se puede hacer en persona, por correo electrónico o mensaje de texto, o de cualquier manera. El empleador presenta al servicio de registro de uPass 14 un documento que se utilizará para anclar un perfil para el nuevo empleado. Además, el empleado envía su credencial 30E. En este caso, puede ser necesario determinar las autorizaciones adjuntas a dicha credencial y confirmar que el empleador tiene una credencial que le permite crear uPasses para un tercero. Tenga en cuenta que este es un nivel superior en autorizaciones y asignar un perfil a alguien que ya tiene un uPass. La asignación de un perfil no implica ninguna validez particular para el uPass en sí mismo. Sin embargo, la creación de un uPass implica una cierta validez, aunque, por supuesto, el nivel de confianza que se adjunta al uPass puede variar dependiendo del anclaje de emisión (en este caso el empleador). En la Etapa S92, el empleador presenta el documento y su credencial al servicio de registro de uPass 14. El servicio de uPass crea un perfil de uPass para el nuevo empleado, utilizando el documento como documento de emisión y con un nivel de confianza asociado con el anclaje de emisión. Se une una credencial a cada perfil asociado con este uPass, y la credencial asociada con el perfil anónimo se envía al nuevo empleado como se muestra en la Etapa S96. Si el dispositivo del nuevo empleado no se ha inscrito y no es conocido por el uPass, se hacen algunas disposiciones apropiados para suministrar la credencial 30” al nuevo dispositivo del empleado. En la Etapa S98 se emite una credencial de reemplazo al empleador.

La Figura 2 ilustra un servicio de cuenta 29 que proporciona un medio para gestionar un uPass, que incluye la inscripción de dispositivos y la especificación de perfiles de autorización de usuario.

Perfiles de autorización

Como se ha señalado anteriormente, un perfil de uPass consiste en datos personales y una fotografía que se pueden utilizar juntos como una identidad cohesiva. Cada credencial de uPass está anclada a un perfil y un usuario de uPass puede tener más de una credencial activa en cualquier momento. Sin embargo, solo una credencial puede estar activa en un momento específico en un dispositivo determinado.

Cada perfil disponible para uso con una cuenta de uPass se debe asignar a ella por una Autoridad de Emisión de Documentos de terceros, de la cual el propio controlador del sistema de uPass es un ejemplo. Cuando se crea una cuenta de uPass, tiene al menos tres perfiles asignados por el sistema de uPass:

1. un perfil anónimo 28a que se puede utilizar para confirmar la identidad pero no revela información;

2. un perfil de mayoría (verificación de edad) 28b que revela la fecha de nacimiento del usuario de uPass;

3. un perfil de nombre 28c que revela el nombre del usuario de uPass como se presenta en sus documentos de registro.

Cada vez que las credenciales se transmiten a un dispositivo, siempre están unidas a un perfil específico en la base de datos en la Figura 3b, y el perfil anónimo es el perfil predeterminado para las interacciones, a menos que el usuario de uPass especifique lo contrario.

Para cambiar las credenciales del perfil, el usuario de uPass debe realizar una autenticación mejorada con su credencial actual contra en el servicio de inscripción de uPass para adquirir una lista de los perfiles disponibles actualmente para su cuenta. Esto no es necesario hacer para cada cambio de perfil, ya que la información se puede almacenar en caché localmente en una aplicación de uPass, por lo que la lista solo se necesita regenerar cuando se adjuntan nuevos perfiles a la cuenta de uPass o se eliminan los perfiles antiguos.

Una vez que hay una lista de perfiles disponible, el cambio entre estos perfiles se puede realizar utilizando una autenticación estándar con una credencial existente, que se reemplaza por una nueva credencial unida al perfil deseado.

Todos los cambios de perfil dan lugar a un registro de seguridad en el sistema de uPass.

Estructura del perfil

Como se muestra en la Figura 3a, un perfil consiste en un conjunto de pares de clave valor. Cualquiera de los dos puede considerarse un campo binario arbitrario. Un conjunto puede ser uno o más pares de clave valor.

Anonimato reconocible

La base sobre la que se construyen todos los demás perfiles es el Perfil Anónimo 28a, que confirma que su portador es un usuario de uPass y proporciona como ítem de datos una fotografía actual. Cuando el perfil se publica a un tercero, permite que el tercero confirme mediante inspección visual que el portador del uPass es realmente la persona para la que es válido. Un perfil se publica en el procedimiento de validación que se describe más adelante.

La idea de consultar una credencial anónima para confirmar la identidad puede parecer extraña, sin embargo, en una realización de la invención, el sistema de uPass acompaña a la confirmación con un recibo que permite a la parte validadora referenciar de manera indirecta y anónima el uPass que acaba de ser validado.

Perfiles asignados

El poder de un uPass radica en la capacidad de su propietario para presentar diferentes puntos de vista sobre su identidad o derechos en diferentes circunstancias. Para evitar abusos, se pueden imponer varias restricciones: 1. los perfiles para cualquier cuenta de uPass solo pueden ser creados por terceros, teniendo en cuenta que el controlador de uPass 116 es un tercero en este sentido;

2. cuando se crea un perfil, se debe crear para una cuenta de uPass específica;

3. el perfil asignado está unido a un perfil específico en la cuenta del creador (de esta manera, el perfil de un creador se convierte en un ancla de confianza 110);

4. y se le asigna una etiqueta característica por el creador;

5. una vez creado el perfil no se puede editar;

6. sin embargo, se puede suprimir o reemplazar por su creador;

7. y cuando se utiliza, el creador del perfil siempre se anuncia al validador;

8. lo que permite interrogar la cadena de fiable hasta el sistema de uPass.

La etiqueta de característica se puede utilizar para distinguir perfiles entre sí. Por ejemplo, cada etiqueta podría llamar a un indicador visual para que se visualiza en el dispositivo móvil.

Perfiles y privacidad

Una vez que se ha asignado un perfil a una cuenta de uPass, el propietario de esa cuenta de uPass debe elegir activamente utilizar el perfil en una validación para que esté disponible para otro usuario. Es decir, la credencial creada a partir de ese perfil debe hacer que se envíe un enlace a ese perfil a un validador. Un usuario puede tener más de un perfil, por lo tanto más de una credencial, almacenada en los mismos dispositivos diferentes, es decir, solo hay una credencial por dispositivo por persona. [cuando haya más de un perfil, un usuario puede distinguir los mediante los indicadores visuales de las etiquetas características].

El creador del perfil puede requerir explícitamente el uso de ese perfil al realizar una validación, en cuyo caso si se utiliza cualquier otro perfil, se producirá un fallo en la validación. Esto garantiza que mientras exista el perfil asignado, el usuario de uPass solo podrá validar su identidad con ese perfil y que se rechazará el uso de cualquier otro perfil. Esto se describe más adelante en relación con la uPass Connect.

No hay forma de que un tercero enumere todos los perfiles asociados con una cuenta de uPass.

Almacenamiento de perfiles

La información del perfil se encuentra en dos lugares. Los datos subyacentes se versionan y se conservan en el almacén seguro 24, mientras que el estado actual de los datos de perfil se publica en una caché de clave valor segura 35. Esta es una premisa de seguridad subyacente importante del sistema de uPass - a los terceros no se les da ninguna información de acceso a la tienda segura 24 en sí misma.

Publicación del perfil

Un perfil contenido en el almacén seguro 24 se publica (en una ubicación de la memoria 35) cada vez que se une una credencial a este. El perfil publicado tiene ciertas propiedades:

• tiempo de caducidad (y/o sello de tiempo de publicación);

• Fotografía o un enlace a una fotografía;

• Contenido de perfil cifrado (pares clave/valor, etc.);

• Clave simétrica aleatoria;

• Un URI que se resuelve en el contenido del perfil cifrado;

• Un URI que se resuelve en el creador del perfil

Cada vez que se produce la publicación el contenido del perfil se cifra con una clave simétrica generada aleatoriamente diferente 60 y, a continuación se almacena en una ubicación de la memoria 35 a la que se puede acceder a través de un URI generado 62.

Garantía de autenticidad

Cada cuenta de uPass es capaz de adjuntar perfiles a otras cuentas de uPass, lo que permite a las personas anotarse entre sí con apodos y otra información social, así como garantizar la confiabilidad de esa información. Como tal cada uPass en sí mismo es un ejemplo de una Autoridad de Emisión de Documentos con baja confianza en la confiabilidad. Cuando un usuario de uPass adjunta un perfil a otro usuario de uPass, el adjunto se ancla a un perfil existente (anclaje de confianza 110) en su propia cuenta de uPass.

Además de adjuntar un perfil a una cuenta de uPass, los usuarios de uPass pueden garantizar la veracidad de un perfil adjunto a otra cuenta a solicitud de ya sea el creador del perfil o del destinatario del perfil. A medida que aumenta el número de usuarios de uPass dispuestos a garantizar un perfil asignado, también lo hace la confianza que se puede depositar en la información contenida en ese perfil.

Autoridades de emisión de documentos

La garantía de autenticidad proporciona un medio por el cual las cuentas de uPass se pueden anotar con perfiles, sin embargo, estas son fuentes de información potencialmente de baja calidad, más cercanas al rumor que a una declaración de identidad fundamentada. Una autoridad emisión de documentos autorizada es una fuente reconocida de información de identidad de alta calidad anclada a documentos del mundo real.

Una vez que un usuario de uPass se convierte en una Autoridad de Emisión de Documentos, se le permite solicitar información de un usuario de uPass y utilizarla para anotar cuentas de uPass con un nivel de confianza superior al que ofrece el mecanismo de garantía estándar.

Ciclo de vida

Si bien las credenciales uPass están ancladas por un pasaporte 10, se puede hacer que caduquen cuando caduque el pasaporte. Esto requiere que se aconseje a los usuarios de uPass que actualicen sus documentos registrados tan pronto como se emita su nuevo pasaporte para garantizar la continuidad del servicio.

Se puede proporcionar un período de notificación de ocho semanas cuando el pasaporte registrado está a punto de expirar para permitir el tiempo de respuesta variable.

Cuando se implementa el soporte para otros documentos de identidad, la situación se volverá más compleja. Cada documento contribuirá a la fiabilidad contingente del uPass y, mientras esté por encima de un cierto nivel, el uPass permanecerá activo con advertencias periódicas al usuario con respecto a la caducidad real y pendiente del documento.

Uso

El escenario inicial para el uso de uPass gira en torno a encuentros cara a cara en los que se utilizaría un pasaporte o documento equivalente para respaldar la identidad.

Siempre que un portador de uPass desee autenticar su identidad, debe presentar una credencial (por ejemplo, un código QR) generada a partir de un identificador aleatorio único proporcionado por el sistema de uPass. El destinatario de esta credencial es un validador de uPass que se autentica en el servicio de validación de uPass cada vez que valida la información recibida de un Portador. Después de la validación el Validador decide cómo proceder.

Supresión

Es posible que los usuarios de uPass deseen suprimir perfiles particulares o toda su identidad de uPass, y esto es compatible con el servicio de inscripción. Esto implica la supresión de todos los datos personales e identificadores de dispositivos y la caducidad de todas las claves emitidas.

Es posible que exista un requisito legal para mantener los metadatos de auditoría asociados con una identidad de uPass durante un período de tiempo específico, por lo que la supresión puede implicar un componente diferido. Suspensión

Cuando un usuario de uPass ve un uso indebido, puede denunciar al usuario infractor y se impondrá una suspensión de la cuenta mientras se investiga el asunto. El sistema de uPass puede proporcionar una suspensión uPass de 7-14 días. Cuando se suspende, un uPass debe indicar que la identidad del uPass ha sido suspendida.

La suspensión no puede ocurrir sin la intervención de una auditoría y se puede realizar una investigación sobre las razones de la suspensión. Los mecanismos y procedimientos para ello están fuera del alcance de este documento, pero deben ser claramente proporcionales y estar diseñados para minimizar o prevenir la suspensión maliciosa. Revocación

Cuando exista la sospecha de un uso indebido grave, un uPass se puede revocar. La revocación es similar a la supresión, pero puede ser necesario registrar información adicional sobre el usuario para evitar que vuelva a unirse a uPass dentro de un período de tiempo establecido.

Expiración

En ciertos períodos de tiempo poco frecuentes (regidos por el tiempo de caducidad 68), se le puede pedir a un Usuario de uPass que cree un nuevo uPass.

Si todos los documentos de identidad de anclaje de un usuario de uPass caducan, esto debería desencadenar automáticamente una solicitud para emitir un nuevo uPass.

Múltiples uPasses

Los usuarios pueden tener más de una cuenta de uPass en un momento dado, sin embargo, la implementación de múltiples perfiles dentro de un uPass debería reducir el grado en que esto ocurre. Por ejemplo, una mujer casada que desee utilizar un uPass tanto en su apellido de soltera como en su nombre de casada, podría hacerlo con múltiples perfiles en un solo uPass, en lugar de necesitar múltiples uPasses.

Inscripción de dispositivos

Cada cuenta puede tener uno o más dispositivos 12a, 12b asociados a ella en un momento dado. Para inscribir nuevos dispositivos en una cuenta de uPass, se debe realizar una transacción de validación auditada entre este dispositivo y un dispositivo que ya está inscrito en la cuenta del usuario de uPass.

1. Tomar una selfie;

2. Intercambio de credenciales estándar entre los dos dispositivos (esto significa que la aplicación de validación 52 en un dispositivo escanea la credencial 30 ofrecida por el otro dispositivo, y viceversa);

3. Cuando un nuevo dispositivo está en línea, el servidor pregunta si la credencial es válida;

4. Si la credencial es válida se inscribe el nuevo dispositivo.

Reinscripción de dispositivos

Si la cuenta de uPass tiene al menos otro dispositivo asociado con una credencial válida, la reinscripción sigue el proceso descrito anteriormente para la inscripción del dispositivo.

Recuperación de cuenta de uPass

Si el usuario de uPass todavía tiene posesión de un dispositivo que se ha inscrito, la recuperación de la cuenta se realiza de la misma manera que la reinscripción del dispositivo con credenciales invalidadas. De lo contrario, el usuario de uPass puede volver a registrarse utilizando cualquier documento de registro asociado con la cuenta.

Revocación de dispositivos

Un usuario de uPass puede revocar la autorización de cualquier dispositivo actualmente inscrito en su cuenta. Esto invalidará cualquier credencial que tengan actualmente asociada con el dispositivo revocado.

La revocación del dispositivo no necesariamente resulta en la suspensión de uPass.

Registro de dos factores

Como se mencionó anteriormente, cada identidad digital tiene ítems de datos derivados de los documentos de identidad en un proceso de registro. Al obtener datos de los documentos de registro, se podría suponer que la transmisión de los datos de calidad de NFC (comunicación de campo cercano) y OCR (lector óptico de caracteres) sería suficiente para confirmar que los datos del pasaporte son válidos, sin embargo, la adquisición de ambas fuentes de información a través del mismo dispositivo no deja forma de confirmar que los datos no han sido manipulados antes de la transmisión. Para ello, se puede utilizar un segundo vector de transmisión, preferiblemente que implique un agente fiable y/o un dispositivo de adquisición de datos, y alguna forma de firma estandarizada del registrante que se pueda auditar.

En una realización del proceso de registro, el registrante presenta una fotografía del registrante tomada con el mismo dispositivo utilizado para capturar datos de registro, con marca de tiempo y etiquetado con metadatos que comprenden el tipo de dispositivo, el sistema operativo, la geolocalización y la dirección de red. Se capturarán los mismos metadatos para cada ítem de datos de registro capturado utilizando el dispositivo.

Esta fotografía y los metadatos asociados proporcionan un registro de auditoría que se puede utilizar para ayudar a identificar registros fraudulentos. Un porcentaje de los registros se comprueba manualmente en el momento de la presentación para garantizar una coincidencia visual entre la fotografía y el elemento fotográfico del documento de identidad registrado (por ejemplo, foto de pasaporte).

Preferiblemente, un servicio de verificación facial 40 compara estas fotografías en todos los casos y, cuando haya un bajo nivel de confianza en que las fotos representen a la misma persona, también se marcará para una inspección visual manual. En lugar de una sola fotografía estática, se pueden utilizar fotogramas tomados de breves clips de vídeo para capturar una sensación de vitalidad. En algunas realizaciones, solo se toma un solo fotograma, ya que se ha encontrado que utilizar varios fotogramas no mejora la precisión del software de verificación facial.

Los datos capturados por la cámara del dispositivo están sujetos al procesamiento OCR 42 cuando llegan al servicio de registro 14a en el servidor de UPass, para extraer ítems de datos del documento de identidad.

Una firma digital se genera a partir de la suma de datos no cifrados. Cada ítem de datos capturado se cifra mediante el bloque de cifrado 44. La firma digital se utiliza para anotar cada ítem de datos cifrado por separado antes de enviarlo al servicio de registro. Estos ítems de datos cifrados son descifrados por el servicio de registro y la firma digital se verifica, lo que garantiza la integridad de toda la presentación de registro.

En una realización, para fortalecer aún más la integridad, los distintos ítems de datos de registro se transmiten a puntos de acceso separados identificados por la aplicación de registro 22 y se cifran con claves simétricas separadas. Al igual que con todas las claves simétricas emitidas por el sistema estas son almohadillas de un solo uso - claves utilizadas una sola vez y, por lo tanto, se sabe que son únicas.

Para implementar el sistema de autenticación de dos factores, el registrante requiere un teléfono inteligente 12 con acceso a Internet, que sea capaz de comunicarse a través de HTTPS e incluya una cámara de calidad razonable (digamos 5MP). La capacidad NFC es un extra opcional útil.

El proceso de registro

El proceso de registro se describirá con referencia a las Figuras 4a y 4b en base al uso del dispositivo móvil 12 tal como un teléfono inteligente o un ordenador tipo tableta con una aplicación nativa. Esta aplicación adquirirá las fotos, NFC y metadatos necesarios para el empaque y la presentación al servicio de registro.

El flujo de trabajo de registro comprende las siguientes etapas:

S1/S2. El registrante 20 inicia una transacción de registro al activar un icono en el teléfono inalámbrico 12, que crea (S2) un mensaje electrónico R1 que contiene una clave simétrica aleatoria k1, de al menos 256 bits, que se enviará a través de HTTPS al servicio de registro de uPass 14a. El algoritmo simétrico preferido es AES-256 operado en modo GCM.

S3/S4 El servicio de registro 14a envía una respuesta R2 cifrada con la clave del registrante:

1. tres claves simétricas únicas de 256 bits k2, k3, k4;

2. tres conteos de rondas distintos.

Un conteo de rondas es un número entero positivo que indica al cliente cuántas veces debe realizar de forma iterativa una función inicializada con un valor de datos de interés. En este caso, utilizamos el conteo de rondas para especificar cuántas iteraciones realizar al generar un valor hash SHA-2, que es una defensa contra los ataques de la tabla arcoíris.

Esta respuesta R2 está empacada en una cookie marcada con las banderas solo HTTP y HSTS

S5. El registrante utiliza su dispositivo 12 para capturar ítems de datos para una solicitud de registro: 1. el dispositivo realiza la lectura opcional del chip NFC;

2. capturas de cámara:

1. escaneo de documento de identidad;

2. foto del registrante (selfie).

56. Se registran los metadatos que comprenden la marca de tiempo, la dirección IP y la geolocalización;

57. Luego esto se adjunta a cada ítem de datos que se va a presentar junto con el conteo de ítems;

se genera una firma digital DS para la solicitud de registro utilizando HMAC.

58. Cada ítem de datos se cifra con una de las claves simétricas k2, k3, k4 para crear un BLOB respectivo; la firma distintiva se anexa a cada ítem cifrado;

el registrante acepta los Términos y Condiciones del Servicio de uPass;

cada ítem cifrado se envía a un punto de acceso de red independiente EP1, EP2, EP3. [

59. Los BLOBS (ítems de registro) se recogen en el servicio de registro 14a; se comprueban los códigos geográficos y las direcciones IP para cada ítem de datos;

si se superan todas las comprobaciones entonces se procesan los datos de registro (véase la Figura 5 para un formato de pasaporte digital):

1. escaneo de pasaporte pasado al servicio de OCR para extraer MRZ, fotografía y firma;

2. Los datos de NFC proporcionan DG1, DG5 y DG7 (MRZ, foto, firma);

3. las fotos extraídas se comparan con la selfie del registrante mediante el servicio de reconocimiento facial 40. 510. Si todo coincide entonces se puede crear una cuenta de uPass con:

1. un perfil anónimo 28a;

2. un perfil de ID con foto 28b;

3. un perfil de mayoría (que indica la edad) 28C;

4. un perfil de nacionalidad (elemento de la figura*). ;En algunos casos, solo el perfil anónimo 28a puede ser suficiente ;511. Las credenciales de uPass se proporcionan a la aplicación del registrante para el perfil anónimo (el perfil predeterminado). Por ejemplo, una credencial es una secuencia digital aleatoria válida para un solo uso - se puede incorporar como un código QR 16. ;El servicio de registro 14a está soportado por una caché en memoria 24 en el almacén seguro que contiene un conjunto de trabajo de elementos de datos relacionados con el registro activo actual para transacciones, que incluyen: ;1. para la dirección IP de cada registro de cliente activo ;1. ID del dispositivo; ;2. clave simétrica; ;3. Datos de registro [k1]: ;a. claves simétricas de registro [k2, k3, k4] ;b. ítems de datos de registro cifrados recibidos; ;c. ítems de datos descifrados. ;4. mensaje de creación de cuenta; ;5. credenciales de la cuenta ;Para mejorar la seguridad, es posible que se imponga el requisito de que los datos sean transitorios y nunca se almacenen en el disco. ;;Cada clave proporcionada por el servicio es generada por el almacén seguro 24, lo que garantiza que todas las claves emitidas sean únicas. La falsificación de transacciones de registro es imposible ya que las claves proporcionadas por el servidor de registro se generan aleatoriamente y no se pueden predecir, por lo tanto, no hay forma de utilizar las claves de una transacción para adivinar las claves que se utilizan por otra transacción. La garantía de unicidad garantiza que al intentar reutilizar un conjunto de claves anterior se desencadenará un evento de seguridad. ;;Una vez que se han recibido y descifrado todos los ítems de datos esperados para el registro, el escaneo del pasaporte descifrado se envía al servicio OCR 42 y los datos devueltos se utilizan como base para un mensaje de creación de cuenta. Esto se comprueba contra los datos NFC recibidos para confirmar que las dos fuentes de datos presentan la misma identidad y, si este es el caso, las fotografías integradas se comparan con la fotografía de confirmación del registrante en el servicio de reconocimiento facial 40 para garantizar una semejanza visual. ;;Un porcentaje de los registros entrantes se puede verificar manualmente en esta etapa para garantizar que los procesos de OCR y reconocimiento facial funcionen correctamente, aunque esto no es esencial. ;;Si los datos de registro superan estas pruebas, el mensaje de creación de la cuenta se pasa al almacén seguro 24, donde se confirma su unicidad. Se crea un almacén de datos para la cuenta que contiene declaraciones de identidad, cada una anclada a su documento fuente, y los tres o cuatro perfiles iniciales 28a, 28b, 28c, 28d creados para esta cuenta. Alternativamente, las declaraciones de identidad se podrían lograr mediante la firma digital de los documentos fuente. ;;A continuación, se genera una credencial 30 adecuada para el dispositivo del registrante utilizando el perfil predeterminado (anónimo). La credencial se almacena en el dispositivo del registrante y se le permite el acceso al perfil. El almacén seguro 24 ahora contiene registros de perfil a los que se puede acceder utilizando esta credencial. ;Después de un registro exitoso, los metadatos del dispositivo, por ejemplo, una combinación del tipo de dispositivo registrado y el sistema operativo, se utilizan para proporcionar enlaces de descarga para las aplicaciones de uPass apropiadas desde la página de perfil del usuario. ;;Para satisfacer algunos casos de uso en los que un comerciante busca la verificación de un usuario, el propio comerciante debe estar registrado. ;;El proceso de registro de comerciantes es similar al proceso estándar de registro de usuarios, pero utiliza diferentes documentos primarios. ;;Para la jurisdicción del Reino Unido, un comerciante puede comprender cualquiera de: ;;entidad corporativa registrada; ;;Comerciante individual: ;;asociación; ;;organización benéfica registrada; ;;club; ;;sociedad. ;;Dado que un comerciante registrado es una organización, no un individuo, existe el requisito de hacer una distinción entre quién es el propietario del uPass (el comerciante) y quién fue designado como administrador (una o más personas). ;;En la figura 11a se muestra una ilustración gráfica que ejemplifica el proceso de registro ;;Anclajes de confianza ;;Una faceta importante del sistema de uPass es la naturaleza de autovalidación entre los titulares de uPass. Es decir, los titulares de uPass pueden confirmar su confianza en la identidad de los demás. Cada uPass puede actuar como un ancla de confianza 110 para los perfiles individuales de otros usuarios de uPass. ;;Internamente, cualquier ítem de datos agregado a un perfil gana una fiabilidad contingente, que es una función tanto del número como de la calidad de las validaciones realizadas por otros usuarios de uPass para establecerlo. ;;Una vez introducidos en un perfil, estos ítems de datos también se pueden utilizar en otros perfiles, pero cuando están, la fiabilidad contingente asociada con estos perfiles se convierte en la del ítem de datos de menor fiabilidad del perfil. ;De esta manera, siempre hay una degeneración de la fiabilidad contingente representada por los documentos de registro fuente, que solo se puede compensar con un número estadísticamente significativo de validaciones por parte de otros usuarios de uPass en perfiles con un alto nivel de fiabilidad contingente. ;;Perfiles de terceros ;;Los documentos de registro proporcionan un medio por el cual se puede confirmar la identidad con un alto nivel de confianza. Sin embargo, hay casos de uso en los que la identidad que una persona podría necesitar presentar no se deriva de dicha fuente, sino más bien de su empleo o membresía en una organización particular. ;;Para permitir esto, un uPass puede tener perfiles asignados por terceros, y la fiabilidad contingente de estos perfiles es la exigida por la parte de autorización. Ninguno de los ítems de datos asociados a un perfil asignado se agrega al conjunto de ítems de datos disponibles para uso en crear perfiles adicionales o modificar perfiles existentes, y el perfil asignado solo se puede modificar por la parte de autorización. Para asignar un perfil, un tercero debe ser un usuario de uPass con una credencial válida. Presenta esta credencial y, siempre que sea válida, recibe un formulario para introducir datos sobre el nuevo perfil de uPass. Esto se registra como antes y se genera y devuelve una credencial Esto se puede pasar al propietario del nuevo perfil. ;;Un perfil asignado sigue existiendo hasta que la parte de autorización lo cancele o hasta que pase una fecha de caducidad preasignada. ;;Privacidad en los gráficos sociales ;;El sistema de uPass contiene una serie de gráficos sociales que identifican eficazmente a un individuo en relación con el empleo, los amigos, la documentación oficial, las relaciones transaccionales y la ubicación. El acceso completo a estos gráficos es privado para el sistema de uPass. ;;Una excepción principal es cuando un usuario de uPass realiza una validación basada en un perfil asignado. En este caso, se proporcionan detalles para la parte de autorización del perfil como una protección adicional para la parte que realiza la parte de transacción. ;;Una aplicación del sistema de uPass es la intermediación de la fiabilidad entre dos usuarios del sistema de uPass, uno un individuo que busca confirmar su identidad y el otro interesado en utilizar esa confirmación para validar la elegibilidad para algún servicio o interacción. Esto puede verse como una sola transacción que comprende la autenticación de las identidades de las partes. ;;Esta transacción de fiabilidad requiere dos modos de aplicación separados, uno en el dispositivo móvil de un usuario para confirmar su identidad (aplicación 50), el otro en el dispositivo de un comerciante (aplicación 52) para verificar la confirmación y luego determinar si el usuario está autorizado a realizar una acción particular. ;;Para confirmar la identidad se requiere la presentación de una credencial en el dispositivo 30, ya sea en forma visual tal como un código QR o un código de barras, o como un blob binario transmisible para uso con NFC o tecnología similar. La aplicación de autenticación de uPass presenta una credencial adecuada 30 a un lector de uPass 54 en la aplicación 52, que a su vez la envía al servicio de autorización 14b para autenticación. Si esta operación de autenticación es exitosa, la aplicación de lectura de uPass 52 recibirá acceso a uno o más perfiles uPass y el usuario podrá confirmar su identidad en base a los ítems de datos del perfil que ahora puede ver tal como una foto. ;;Cuando se genera una credencial nueva, se une [a un perfil individual asociado con el usuario de uPass (véase la base de datos en la Figura 3b). Cuando se utiliza la credencial, la información de este perfil pasa a estar disponible para la parte validadora en la transacción de fiabilidad. ;;Para mayor seguridad, el perfil no contiene ningún enlace con el usuario de uPass. Esta precaución garantiza que obtener acceso a un perfil específico no proporcione un medio por el cual se pueda acceder a todos los perfiles asociados con el usuario de uPass. Solo se expone a la otra parte la información proporcionada en el perfil asociado con la credencial utilizada, junto con cualquier información que haya publicado en el uPass validado en forma de una serie de perfiles asignados. ;;Como medida de seguridad adicional, las credenciales emitidas se pueden unir a la dirección de red 64 del dispositivo, por lo que si el dispositivo cambia de dirección de red, la credencial también se invalida. ;;En ningún momento se expone el identificador de identidad digital de la parte afirmante 26. Esto es esencial para la integridad del sistema, incluso para casos de uso casual. De manera similar, no se revela ninguna información personal sobre la parte afirmante más allá de la necesaria para negociar la fiabilidad. ;;Resumen del proceso de creación de credenciales ;;Este proceso se lleva a cabo mediante el código de gestión de identidades ejecutado por el procesador 114 (o mediante cualquier mecanismo informático adecuado) en el registro de un nuevo perfil, y en cada ocasión en que se utiliza el perfil. ;1. determinar el número de identificación del dispositivo de un nuevo dispositivo cuando se registra; ;2. calcular el SHA-2 HMAC de este número de identificación del dispositivo; ;3. almacenar este número de identificación del dispositivo de forma segura; ;4. para cada credencial generada: ;1. crear un valor de sal aleatorio (preferiblemente de al menos 8 bytes de longitud) ;2. combinar esto con el número de identificación del dispositivo almacenado para crear un número de credencial único; 3. realizar el hash SHA-2 de forma iterativa con el número de credencial almacenado como valor semilla; ;4. el número de iteraciones se elige aleatoriamente dentro de los límites especificados; ;5. el token resultante es la credencial que se pasa al dispositivo. ;5. se crea una entrada de base de datos con clave para la credencial generada 30 que contiene (véase la Figura 3b); 1. una clave de referencia aleatoria 60 específica para esta credencial; ;2. un URI 62 capaz de proporcionar el perfil al que está unida la credencial; ;3. la dirección de red 64 del dispositivo para el que es válida la credencial; ;4. un enlace 66 al usuario de uPass para el que se generó esta credencial; ;5. el tiempo de caducidad 68 de la credencial; ;6. otros metadatos 70 relacionados con el ciclo de vida de las credenciales ;Las credenciales son de “uso único” y “restringidas”. Cada credencial generada es específica tanto para el dispositivo como para el perfil de uPass. ;Credenciales de uso único ;Una característica del sistema de uPass es permitir que un usuario presente un teléfono inteligente/portador tipo tableta, etc. para validar su identidad. Una posibilidad es utilizar como credencial en el dispositivo su número de identificación del dispositivo. Sin embargo, esto tiene el inconveniente de que una vez asignado no se puede cambiar fácilmente y también revela información sobre el dispositivo que podría ser utilizada por un atacante. Una alternativa mejorada es utilizar una clave que se genera en base al número de serie utilizando un algoritmo de hash tal como SHA-2 de forma iterativa. Esto implica crear un hash para el número de serie y, a continuación crear una secuencia de hashes salados con este valor como punto de partida. ;Solo se almacena el HMAC del valor hash inicial, lo que permite describir la identidad de un dispositivo sin conocer su número de identificación preciso del dispositivo y, por lo tanto, evitar que cualquier persona con acceso físico al almacenamiento seguro 24 invierta el proceso para determinar el número de identificación del dispositivo y use esta información de manera maliciosa. ;Para capturar credenciales de un dispositivo, una aplicación de uPass escanea un código QR generado que contiene la credencial o recibe las credenciales a través de otros medios, tales como NFC, iBureau, código de barras, etc. Credenciales restringidas ;Cada credencial generada es específica tanto para un dispositivo como para un perfil de uPass. Esto evita que las credenciales se transfieran entre dispositivos y significa que cualquier dispositivo determinado solo puede presentar un perfil a la vez. ;Las credenciales se generan al crear un valor de sal aleatorio y combinarlo con el número de identificación del dispositivo. A continuación, el resultado se utiliza como valor de semilla inicial para un valor hash SHA-2 generado de forma iterativa, y el número de rondas de iteración se determina de forma aleatoria. ;Recibos de transacciones ;Cada vez que se produce una transacción de validación, se generan dos recibos 32e, uno enviado a la parte validadora (es decir, el comerciante - VALIDADOR) y otro a la parte validada (por ejemplo, el usuario de uPass - PORTADOR). Un recibo contiene cuatro piezas de información: ;1. la clave de referencia aleatoria 60 asociada con la credencial específica utilizada; ;2. el perfil URI 62 al que se unió la credencial presentada por la otra parte; ;3. el URI de una lista de todos los perfiles asignados actualmente por el destinatario a la otra parte. ;4. la marca de tiempo ;La clave de referencia aleatoria 60 actúa como un identificador de transacción que se asocia a un par específico de recibos y, por lo tanto, a un par específico de credenciales. ;Cuando se genera un recibo, el perfil correspondiente se cifra con la clave simétrica y se publica en un Almacén de Perfiles Publicados 35 en un URI generado aleatoriamente. Por lo tanto, ambos recibos generados para una transacción utilizan la clave simétrica para cifrar sus perfiles asociados. ;Estos recibos de transacciones proporcionan la base para que las aplicaciones interactúen con un uPass, como se explicará más adelante en la discusión de los perfiles de uPass. ;Cada dispositivo contiene un libro de recibos 300 (Figura 1a) que contiene un número arbitrario de recibos de transacciones anteriores. Cuando un usuario desea demostrar que se ha producido una transacción, puede presentar el recibo como un código QR, etc., que contiene solo la clave de referencia aleatoria 60 para la credencial utilizada. Esto puede ser conciliado por un comerciante u otro usuario de uPass con su propio libro de recibos. ;Una copia del recibo se mantiene en línea en el libro maestro de recibos 31, que contiene todos los recibos generados hasta la fecha. ;Autenticación ;Un dispositivo cliente debe estar registrado previamente y autenticarse para realizar una validación de uPass para un perfil determinado. ;Autenticación de cliente estándar ;Cada dispositivo registrado contiene una única credencial de un solo uso para cada usuario de uPass en el que esté registrado. Al presentar la credencial, se realiza una autenticación implícita, que se considera fallida si la credencial es desconocida, ha caducado o está invalidada. También existe una pequeña probabilidad de que una credencial válida se invalide (como una comprobación de seguridad adicional aleatoria) al recibirla para forzar un error de autenticación por motivos de seguridad. ;Se puede llevar a cabo una autenticación mejorada cuando falla la interacción de autenticación estándar o cuando el caso de uso lo requiere. ;Autenticación de cliente mejorada ;Algunas transacciones requieren un nivel de confianza más alto que la norma. Para estos, se captura una foto de cara completo y se utiliza el reconocimiento facial para identificar transacciones potencialmente cuestionables. Debido a que el reconocimiento facial nunca es 100% preciso, no se evita la autenticación estándar basada en errores de reconocimiento facial si las credenciales son válidas, pero de otra forma se evitan las solicitudes de autenticación mejorada. ;El modo de autenticación de cliente mejorado también existe para proteger las operaciones administrativas y permitir que un usuario de uPass vuelva a autenticarse después de un fallo de autenticación. ;La autenticación de cliente mejorada captura una fotografía del usuario del dispositivo que se compara con la base de datos de reconocimiento facial del usuario de uPass en el que está registrado el dispositivo y, si el reconocimiento falla, se desencadena y registra un evento de seguridad. ;Ciclo de vida de las credenciales ;Las credenciales tienen un ciclo de vida que implica: su creación, que las vincula a un perfil de uPass; su distribución a un dispositivo específico; y su revocación o caducidad. Este ciclo de vida se gestiona únicamente dentro del servicio de validación. ;Cuando se crea una credencial, se registra en el almacén seguro y se etiqueta con los siguientes metadatos 70 para utilizarla como parte de la gestión de su ciclo de vida: ;• el perfil de uPass para el que es válido ;• el momento en que se solicitó la credencial ;• el momento en que se emitió la credencial; ;• las ubicaciones geográficas y de red del dispositivo solicitante en el momento de la emisión; ;;• el tiempo de caducidad (si lo hubiera); ;;• los detalles del dispositivo para la validación que hace que se emita la credencial; ;;• sí o no ha sido revocada la credencial. ;;Cuando se recibe la credencial posteriormente, se pueden comprobar todos estos datos de etiquetado para confirmar si la credencial se está utilizando correctamente. A continuación, el registro se utiliza para crear registros de acciones de auditoría y seguridad en otro lugar del almacén seguro y, a continuación, se invalida. ;;Una credencial puede ser revocada en cualquier momento. Cuando se produce la revocación, el registro de la credencial se marca como revocado en el almacén seguro, pero el registro no se procesa en ese momento. Esto permite que el sistema de uPass monitorice el uso de credenciales revocadas y utilice los metadatos resultantes para ayudar en el análisis y la prevención de fraudes. ;;Una vez que se revoca o invalida una credencial, no se puede restablecer como válida. ;;La recolección por depuración de credenciales caducadas y revocadas se puede producir en una de estas dos maneras: ;;• cuando se produce una consulta de validación para la credencial; ;;• a través de una tarea de recolección por depuración de segundo plano que recopila credenciales caducadas. ;Manejo de credenciales invalidadas ;;Cuando una credencial ha caducado o ha sido revocada, su uso (es decir, alguien que intenta reutilizar una credencial invalidada para un uso válido) puede indicar que el dispositivo al que se ha vinculado ha sido robado o se ha visto comprometido de otro modo. Esto representa un grave riesgo de fraude. ;;En estas circunstancias, no podemos emitir una nueva credencial para el dispositivo hasta que se haya confirmado que todavía está en posesión del usuario de uPass para el que se creó originalmente la credencial invalidada. ;;Para confirmar esto, tratamos el dispositivo como si fuera un nuevo dispositivo que se inscribe por primera vez, un caso de uso que se trata en la sección sobre Inscripción. ;;Autenticación del validador ;;El dispositivo validador uPass se basa en los mismos principios que un dispositivo de uPass estándar. Para realizar una validación, el dispositivo validador debe presentar una credencial válida para su dispositivo de uPass asociado. Esto asegura que solo los usuarios del sistema de uPass puedan ejecutar consultas en la red de fiabilidad de uPass. ;La credencial del validador se envía como parte de la solicitud. ;;Autenticación del portador: confirmación de una identidad ;;Al limitar la autenticación a una sola consulta de autorización en lugar de una relación transaccional en curso, uPass se puede utilizar para crear un sistema simple de prueba de identidad. Los casos de uso más complejos basados en la venta de entradas para eventos tales como listas de invitados o pases digitales para festivales se pueden construir sobre esto al permitir que el comerciante asigne un perfil a un usuario de uPass con una fecha de caducidad adecuada. ;La Figura 6 ilustra un proceso de autenticación solo al portador. ;;Cuando se produce una autenticación de solo portador, el lector de uPass 54 enviará las credenciales 30 ofrecidas por el cliente 20 en un mensaje 100 al servicio de autorización 14b. A continuación, se comprueba la validez de las credenciales del usuario antes de marcarlas como utilizadas y se devuelve una respuesta 122 al lector de uPass junto con un enlace a un perfil que contiene una fotografía para permitir la confirmación visual de la identidad por el comerciante. ;;La Figura 6 ilustra esquemáticamente una validación en su contexto completo, donde la credencial 30 en un dispositivo está respaldada por una serie de anclajes de emisión 107 que indican la calidad de los documentos de registro 10 y anclajes de confianza 110 que indican el grado en que el perfil ha sido garantizado por otros usuarios de uPass. ;Dado que una credencial 30 es de un solo uso y potencialmente restringida, es posible que, cuando se ofrezca, ya no sea válida. Cuando este es el caso, el servicio 14b puede generar automáticamente una nueva credencial de 30” y publicarla (104) al dispositivo del portador y de allí al validador, o puede ser necesario que el usuario de uPass vuelva a inscribir el dispositivo. ;El proceso de autenticación del portador es como sigue. ;1. el lector de uPass 54 solicita credenciales para la autenticación; ;2. (opcional si el usuario de uPass tiene varios perfiles): el usuario de uPass selecciona un perfil para validar (tenga en cuenta que la validación hará que una nueva credencial se una al perfil y a su dispositivo de uPass); ;3. el usuario de uPass presenta sus credenciales al lector de uPass: ;4. las credenciales están unidas a un perfil de uPass. ;5. las credenciales se envían al servicio de autorización 14b; ;6. sí una credencial ha caducado, el servicio de autorización: ;1. en el caso de que el usuario de uPass haya presentado una identidad válida: ;1. envía una nueva credencial 104 al dispositivo registrado del usuario de uPass; ;2. envía un mensaje de reintento al lector de uPass. ;2. en caso contrario: ;1. envía un mensaje de error de autorización al lector de uPass. ;7. si la credencial es válida: ;1. se invalida la credencial del usuario de uPass; ;2. envía el mensaje 122 al lector de uPass que comprende un enlace a un perfil con una fotografía (¿o la foto en sí?) 8. en todas las demás circunstancias, el servicio de autorización envía un mensaje de fallo de autorización. ;9. las nuevas credenciales se generan y transmiten respectivamente a cada dispositivo de uPass 12. ;Todo este proceso se debe repetir para realizar autorizaciones adicionales, cada vez que se autentican las credenciales del usuario de uPass contra un perfil específico y se produce una cascada de publicación de credenciales. La Figura 6a muestra un proceso de validación en el que se validan tanto la credencial del portador como la credencial del validador, y en el que se emiten recibos. Esta es una descripción más completa del proceso de autenticación del portador descrito anteriormente con referencia a la Figura 6. El usuario del dispositivo de uPass selecciona un perfil. El dispositivo de uPass 12 del portador envía la credencial 30b unida a ese perfil al validador uPass 52, por ejemplo, como un código QR. El validador uPass lee el código QR, selecciona un perfil para utilizar y suministra la credencial de portador 30b y su propia credencial 30v al servicio de validación de uPass. La validación de uPass confirma que la credencial 30v es válida y, si es así, pasa a procesar la credencial 30b. Si la credencial 30b es válida, devuelve (mensaje 112 en la Figura 6) un enlace al perfil unido a la credencial 30b al validador 52. También emite una nueva credencial de portador (nueva) 30b” al dispositivo portador 12 y una nueva credencial de validador 30v” al validador 52. Cada credencial nueva se devuelve con un recibo que se denota 32v para el validador y 32b para el portador. La generación de la nueva credencial en cada caso está asociada con la emisión de un par de recibos (individuales) que no coinciden. En cada par, un recibo se envía al portador y comprende un enlace a un perfil recién publicado del validador y la nueva credencial de portador para uso posterior por el portador, y el otro recibo del par se devuelve al validador y comprende un enlace a un perfil recién publicado del portador y la nueva credencial de validador. Por lo tanto, en la realización de la Figura 6a, se emite un par de recibos para la creación de la nueva credencial para el validador, y se emite un par de recibos para la nueva credencial para el portador. Los dos recibos 32e, 32v comprenden identificadores de transacción coincidentes que identifican la transacción en la que se crearon y los vinculan. Un recibo maestro 32 correspondiente comprende el mismo identificador de transacción (que lo vincula al par de recibos correspondiente) y ambos enlaces, pero no las credenciales. ;El recibo 32v puede incluir el enlace a la fotografía del portador en el perfil correspondiente. ;En cualquier momento entre transacciones, un usuario puede optar por adquirir credenciales para un perfil diferente. Sin embargo, solo pueden tener una credencial en su dispositivo para un usuario de uPass determinado. ;Las Figuras 6b y 6c muestran detalles adicionales de los recibos 32b, 32v que se generan en la transacción de validación de la figura 6a. Cada uno de los recibos 32b, 32v comprende el mismo identificador de transacción 60, que es una clave de cifrado simétrica para la transacción. El recibo del portador 32b comprende un enlace 62v a la versión de la oferta del validador publicada en la transacción de validación, y un valor de confianza 65v asociado al perfil que el portador acaba de presentar (es decir, al que apunta el enlace 63b en el recibo del validador 32v). De manera similar, el recibo del validador 32v comprende un enlace 62b a la versión publicada del perfil del portador, y un valor de confianza 65b asociado con el perfil que el validador acaba de presentar (es decir, al que apunta el enlace 63v en el recibo del portador 32b). Cada uno de los recibos de portador y validador 32b, 32v también comprende un enlace respectivo 63b, 63v a una lista de todos sus perfiles actualmente asignados entre el portador y el validador. ;;Como se señaló anteriormente, además de los recibos al portador y validador 32b (es decir, C'), 32v (es decir, C'<v>), se genera un recibo maestro 32 para la transacción, cuyos detalles se muestran en la figura 6c. El recibo maestro 32 comprende un hash (por ejemplo, HMAC) de la nueva credencial de portador 300b, es decir, H(C'), y un hash de la nueva credencial de validador 300v, es decir, H(C'<v>), donde H denota una función hash criptográfica (por ejemplo, HMAC) que se aplica a esa credencial, generando de este modo un hash de esa credencial. Es decir, el recibo maestro 32 comprende hashes de las dos credenciales nuevas 30b”, 30v” que se emiten al final de la transacción de validación. Las credenciales 30b”, 30v” no se pueden obtener solo de los hashes 300b, 300v. Sin embargo, las credenciales 30b”, 30v” emitidas al portador y al validador respectivamente se pueden utilizar posteriormente para ubicar el recibo maestro 32, incluso después de que se hayan utilizado o hayan caducado. En otras palabras, los hashes 300b, 300b son el primer y segundo índice del recibo maestro 32 respectivamente, que se pueden utilizar para ubicarlo en el libro de recibos maestro 31 cuando (y solo cuando) una de las credenciales 30b” o 30v” está disponible para el sistema de uPass. El recibo maestro se localiza mediante un hash de la credencial disponible para generar un índice de búsqueda, que coincidirá con el índice correspondiente del recibo maestro 32. El libro maestro de recibos 31 se puede implementar de cualquier manera adecuada que permita buscar estos índices, por ejemplo, como un almacén de datos distribuido. ;;El recibo maestro 32 también comprende ambos enlaces 62b, 62v a los perfiles publicados, sus valores de confianza asociados 65b, 65v, y los dos enlaces 63b, 63v a las listas de perfiles - todos los cuales están cifrados con el identificador de transacción 60. Alternativamente o adicionalmente, las versiones publicadas de los perfiles a los que apuntan los enlaces se pueden cifrar con el identificador de transacción. En las realizaciones, el identificador de transacción 60 no se incluye en el recibo maestro 32, ni se almacena dentro del sistema de uPass. Por lo tanto, el contenido del recibo maestro 32 sólo puede ser accedido por el titular de cualquiera de los recibos 32b, 32v en dichas realizaciones. ;;El recibo maestro 32 también puede comprender datos que coincidan al menos con parte de los dos recibos maestros anteriores para el portador y el validador, respectivamente -32' y 32” en la figura 6d, respectivamente. Estos datos tienen la forma de un hash de la credencial de portador ahora utilizada 302b, es decir, H(C), y un hash de la credencial del validador ahora utilizada 302v, es decir, H(C<v>). El hash 302b de la credencial de portador ahora utilizada 30b coincide con el índice correspondiente del recibo maestro anterior 32' que se generó en la transacción en la que se emitió por primera vez la credencial de portador 30b (primer recibo maestro anterior) y el hash 302v de la credencial de validador ahora utilizada 30v coincide con el índice correspondiente del recibo maestro 32” que se generó en la transacción en la que se emitió por primera vez la credencial de validador 30v (segundo maestro anterior recibo). Estos índices son públicos, en el sentido de que no están cifrados con el identificador de transacción 60. Por lo tanto, estos dos recibos maestros anteriores 32' y 32” se pueden ubicar utilizando los hashes de las credenciales del portador y del validador 302b (es decir, H(C)), y 302v (es decir, H(C<v>)) respectivamente. Debido a que los recibos maestros anteriores 32' y 32” se han generado de la misma manera que el recibo maestro 32, uno de los índices públicos del primer recibo maestro anterior 32' coincidirá con el H(C) del recibo maestro actual 32 - se ha generado ese índice en la transacción anterior cuando Cse emitió a la entidad que es el portador en la transacción actual (pero que puede haber sido el portador o el validador en esa transacción anterior); de manera similar, uno de los índices públicos del segundo recibo maestro anterior 32” coincidirá con H(C<v>) del recibo maestro actual 32- se ha generado ese índice en la transacción anterior cuando C<v>se emitió a la entidad que es el validador en la transacción actual (pero que puede haber sido el portador o el validador en esa transacción anterior). A su vez, esos índices de los recibos maestros anteriores 32' y 32” se refieren, de la misma manera que el recibo maestro actual 32, a los recibos emitidos a las entidades en cuestión en las transacciones anteriores (al igual que sus otros índices). ;;Estos dos hashes adicionales 320b, 302v también se pueden cifrar con el identificador de transacción 60. Esto permite que los recibos maestros anteriores 32', 32” se ubiquen en el libro de recibos maestro 31 desde el recibo maestro actual 32 solo cuando la clave de transacción 60 está disponible desde el recibo del portador o validador 30b, 30v. Más aún, el contenido de cada uno de los recibos maestros anteriores 32' 32” y/o los perfiles publicados a los que se vincula, está encriptado con su propio identificador de transacción respectivo, es decir, el identificador de transacción respectivo de la transacción anterior en la que se creó (que es diferente del identificador de transacción actual 60), y por lo tanto solo se puede acceder con el recibo al portador o validador creado en esa transacción anterior. ;;El recibo maestro 32 también comprende la primera y segunda firmas digitales 304b, 304c, generadas a partir de al menos una parte de los respectos maestros anteriores 32', 32” respectivamente y/o hashes de las mismas. Preferiblemente, las firmas y/o los hashes se generan a partir de todos los datos de los recibos maestros, que incluyen sus índices públicos. Es decir, como SIG (32') y SIG (32”). La firma se puede generar utilizando una clave privada conocida solo por el sistema de uPass, y se puede verificar utilizando una clave pública correspondiente para verificar que el recibo es auténtico. Las firmas 304b, 304v también están cifradas con el identificador de transacción 60. ;Los recibos al portador y al validador 30b, 30v están encriptados con las claves 306b, 306c previamente registrados en el sistema de uPass por el portador y el validador respectivamente. (un usuario puede depositar una clave pública o simétrica en el servicio si lo desea, y luego el sistema puede utilizarla para comunicarse con ellos de forma segura). Esto significa que solo el portador y el validador pueden acceder a su contenido respectivamente. ;También es posible tener varias firmas en un recibo maestro generado por diferentes medios, y permitir que un recibo maestro se divida en más de dos recibos al incluir las credenciales y firmas adicionales en el recibo maestro. ;;Validación mejorada ;;Algunas transacciones requieren un nivel de confianza más alto que la norma. Para ello, se puede adoptar un proceso de validación mejorado. ;;1. El portador envía una imagen facial fuera de banda al servidor de UPass, acompañada de su credencial actual y el momento en que se tomó la selfie ;;2. El portador envía al validador su credencial y la imagen facial del portador. ;;3. El validador agrega su credencial al mensaje y la envía al servidor de UPass. ;;El servidor de UPass valida el mensaje y compara los datos de imagen que se enviaron desde el portador al validador con los datos de imagen que se enviaron en una comunicación de banda externa entre el portador y el servidor de UPass. Si la selfie no ha llegado cuando se realiza la validación, el servidor de uPass puede comparar los datos de la imagen que se han enviado al validador con la entrada anterior del portador en su base de datos de imágenes faciales. ;Los datos de la imagen que se envían desde el portador al validador pueden ser un extracto LBP de la imagen facial. ;Tenga en cuenta en el presente documento que una selfie es una imagen facial capturada por el portador utilizando la cámara de su dispositivo móvil, por ejemplo. ;;Autenticación mutua con fiabilidad entre pares ;;Una característica útil del sistema de uPass radica en su capacidad para establecer la fiabilidad mutua entre dos partes, lo que permite un rango más amplio de interacciones que las permitidas por el modo de autenticación del portador. En este caso, cada parte presenta credenciales a la otra para autenticación por el servicio de autorización y se establece una transacción en curso. ;;La ventaja de un modelo transaccional es que las transacciones no se pueden superponer, por lo tanto, cualquier dispositivo solo puede participar en una sola transacción a la vez. Si un dispositivo intenta iniciar una nueva transacción, la transacción anterior se puede terminar automáticamente. ;;Cuando se produce una autenticación mutua, cada parte captura una credencial de la otra parte y la envía al servicio de autorización para autenticación. Si ambos conjuntos de credenciales se autentican, se establece una transacción y cada parte recibe una clave simétrica única que se utiliza para cifrar su comunicación continua con el servidor. Estas claves tienen un límite de tiempo (por ejemplo, un límite de aproximadamente 5 minutos) y, si la transacción está en curso, se reemplazarán cuando caduquen. ;;Una transacción puede permanecer activa durante un período de tiempo indefinido, pero para hacerlo ambas partes deben enviar un mensaje de mantenimiento al servicio de autenticación cuando caduquen sus claves. Si alguna de las partes no proporciona el mensaje de mantenimiento activo entonces la transacción se termina. ;;Como medida de seguridad adicional, cada transacción se puede vincular a los dispositivos específicos utilizados para iniciarla y a un perfil específico para cada parte. ;;Una vez que se inicia una transacción, cualquiera de las partes puede probar las proposiciones de autorización contra el perfil activo de la otra parte durante la duración de la transacción. ;;Autenticación anónima ;;El sistema de uPass vincula la autenticación a un perfil específico (28a....28d), pero deja al usuario de uPass el control de la cantidad de información que revela a los demás usuarios de uPass a través de la selección de su perfil. Por lo tanto, es práctico que dos usuarios de uPass negocien la fiabilidad para un propósito determinado sin revelarse ningún dato personal entre sí - solo para confirmar su apariencia física. Para facilitar esto, cada usuario de uPass tiene un perfil anónimo asociado 28a. ;;Avatares de perfil ;;Una segunda posibilidad de credenciales es el uso de un avatar característico (una imagen, un clip de película o un archivo de audio), que es emitido por el sistema de uPass con una credencial integrada en los datos. Los avatares de perfil con logotipos de la empresa se pueden utilizar para incrustar una credencial. La imagen del avatar se puede presentar a un sitio web o a través de NFC a un dispositivo móvil, y el destinatario la autentifica contra el sistema de uPass y recibe los datos de fuente que se pueden utilizar para confirmar la identidad del usuario. ;;El avatar actúa como un contenedor para las credenciales que, aparte de la necesidad de incrustación y extracción, se manejan exactamente de la misma manera que cualesquier otras credenciales de uPass. ;Cada avatar está unido a un perfil de uPass. En algunas circunstancias, puede haber un límite en el número de avatares permitidos por perfil, aún por determinar. ;;Autenticación basada en web ;;En la descripción anterior, se supone que las credenciales de uPass son almacenadas y leídas por dispositivos móviles que utilizan aplicaciones propietarias. Otro caso de uso que debe abordarse es el de las aplicaciones web convencionales que se ejecutan dentro de los navegadores de escritorio. ;;Esto se conoce en el presente documento como uPass Connect y se ilustra en la Figura 7. ;;uPass Connect ;;uPass Connect proporciona un protocolo mediante el cual el usuario de un sistema de red que desee iniciar sesión en ese sistema puede hacerlo utilizando sus credenciales de uPass en un dispositivo fiable tal como un teléfono o un ordenador tipo tableta. Un caso de uso es para sitios web y aplicaciones, sin embargo, uPass Connect debería ser utilizable con cualquier sistema cliente/servidor capaz de presentar un token único al usuario de uPass. ;;En esta situación, se están realizando dos consultas fiables: ;;• el usuario de uPass 20 está buscando de confirmar la identidad del sistema (servidor web 80) al que está proporcionando una credencial; ;;• el sistema (servidor web 80) está tratando de confirmar la identidad del usuario de uPass 20. ;;En realidad, hay tres actores involucrados en esta transacción, ya que el dispositivo local 173 (por ejemplo, un PC) que se utiliza para iniciar sesión en el sistema necesita adquirir la fiabilidad que se está mediando entre el dispositivo de uPass 73 y el sistema remoto 80. ;;Inscripción en el servidor ;;uPass Connect intermedia la fiabilidad entre un servidor 80 y un dispositivo cliente 12. El dispositivo cliente 12 ya está inscrito para el posible usuario 20 y tiene una credencial 30 unida a un perfil. Sin embargo, para que el servidor interactúe con el sistema de uPass, debe estar inscrito como un dispositivo. Este proceso une (en la base de datos de la Figura 3b) un perfil de uPass 28 para el operador del servidor a una credencial 30 para permitir la interacción. ;Una vez inscrito, el servidor es capaz de crear dispositivos virtuales que luego se pueden utilizar para gestionar el inicio de sesión y el registro iniciados por los posibles usuarios del servidor. ;;Dispositivos virtuales ;;La transacción de validación de uPass requiere que cada credencial de uPass esté unida de forma única tanto a un perfil como a un dispositivo inscrito. Cada vez que un sistema de red establece una sesión mediante al presentar un formulario de inicio de sesión o registro 177 a un usuario visitante de uPass a través de una aplicación de cliente, necesita identificar de forma única esta sesión en el sistema de uPass. Lo que introduce la necesidad de un dispositivo virtual transitorio. Se crea un dispositivo virtual transitorio como parte del procedimiento de establecimiento de sesión, desencadenado por la etapa 71 “Quiero utilizar URI”. Este dispositivo se inscribe mediante una validación estándar de uPass y se le asigna un identificador de dispositivo único. Este identificador de dispositivo debe ser único para el usuario de uPass que proporciona la sesión de uPass Connect. El mismo identificador de dispositivo se puede reutilizar en diferentes usuarios de uPass. ;;Una vez que se ha inscrito el dispositivo virtual, se le emite una credencial 30, que se transmite (etapa 72) en una página web y forma la base para un código QR 179. El cual se visualizará en la página web actualizada 177 emitida después de la inscripción del dispositivo virtual. La aplicación nativa en el teléfono inteligente 12 se puede escanear en este código QR y transmitirlo al servidor de validación de uPass 14. ;;Inversión de fiabilidad ;;En el escenario de validación estándar de uPass descrito en las secciones anteriores, un validador solicita que un cliente (portador) que desee interactuar con él proporcione una credencial de uPass que luego se puede verificar con el servidor de validación de uPass. El sistema de uPass Connect no adopta este enfoque, ya que no hay garantía de que la aplicación cliente se ejecute en un dispositivo capaz de solicitar una credencial del usuario de uPass que busca utilizar el servicio de red. ;;Para evitar esto, el validador de uPass presenta la credencial en forma visual (tal como el código QR 179) a través de la aplicación cliente y el usuario de uPass 20 que busca acceso la escanea (etapa 73) en su propio dispositivo inscrito en uPass 12. Como alternativa al código QR, el escaneo puede ser por NFC, Bluetooth, Wi-Fi, audio o cualquier otro mecanismo de transmisión de datos. Esta flexibilidad permite que el uPass Connect admita casos de uso integrados de Internet de las Cosas. ;En la etapa 74, se realiza una comprobación en un servicio de verificación de URI para comprobar que el FQDN del URI está registrado (etapa 75), se devuelve una confirmación al teléfono inalámbrico (etapa 76). Se puede llevar a cabo una etapa adicional óptimo para mejorar la seguridad, en el que en la etapa 77 el dispositivo 12 envía una dirección de recepción con el token adquirido y su token anterior. Esta dirección de recepción se utiliza para abrir un canal posterior, etapa 716. El servicio remoto confirma la validez al teléfono inalámbrico 12, etapa 716. ;;Este escenario puede desarrollarse de dos maneras. En el caso más común, el portador de uPass 20 está utilizando su dispositivo móvil 12 para obtener acceso a un sitio web a través de una sesión de navegador que se ejecuta en un dispositivo de escritorio o portátil 173 que escanea el código QR que se muestra en la aplicación cliente ;;Sin embargo, existe una segunda posibilidad en la que el usuario de uPass desea conectarse al sitio web desde un navegador o aplicación en el dispositivo que aloja su credencial de uPass. Cuando este es el caso, el código QR se transferirá desde la aplicación del navegador hasta la aplicación de uPass y desde allí se transmitirá al servicio de validación. ;;Una vez adquirida, esta credencial (que se anota con el URI que indica el sistema al que se está intentando conectar la aplicación cliente) se pasa (etapa 77) al servicio de validación de uPass, que luego determina si el URI es válido y conocido, al buscar la credencial en la base de datos de la Figura 3b. Para validar simultáneamente al usuario del dispositivo 20, su credencial se agrega al mensaje en la etapa 77. Suponiendo que se validan las credenciales, se envía un recibo al servidor URI 80 (etapa 78) que determina qué hacer (etapa 710) en base a la identidad validada presentada en este recibo. También se envía un recibo (etapa 79) al dispositivo 12 con los detalles del servidor que aloja el URI, para su visualización (etapa 712) al usuario 20. ;;Requerir un perfil específico ;;Es posible que un servidor que admite el uPass Connect solo desee recibir los perfiles que haya asignado. Esto se puede reflejar en las credenciales utilizadas por sus dispositivos virtuales. ;;Finalización del registro ;;Cuando un usuario de uPass desea registrarse en un servicio que admite un uPass Connect, tiene la opción de realizar una validación de uPass. Esto proporciona al servidor su perfil actual (proporcionando información detallada para un formulario de registro) y un enlace de vuelta que permite publicar un perfil en su cuenta de uPass. ;;Caso de negocio: verificación de edad en línea ;;Uno de los problemas clave que resuelve uPass Connect es la necesidad de que ciertas industrias basadas en la web restrinjan el acceso a sus servicios en respuesta a la legislación de edad mínima. Esto se aplica a los sitios que operan en los sectores de juegos de azar en línea, pornografía, vídeo y venta minorista en general. ;;Los operadores del sitio pueden requerir un perfil de verificación de edad de uPass para determinar la elegibilidad legal de un visitante para acceder a su contenido y tomar las medidas apropiadas en base a esto. Al realizar esta validación, también se crea una pista de auditoría para que los propietarios del sitio puedan demostrar posteriormente su cumplimiento de la ley. ;;Caso de negocio: cookies virtuales ;;Cuando un sitio utiliza uPass Connect para controlar el acceso a su contenido, gana la capacidad de anotar las cuentas de uPass de los usuarios con perfiles específicos del sitio, que se pueden consultar en visitas posteriores. Estos se pueden utilizar para almacenar información arbitraria y, por lo tanto, tener una función similar a la de las cookies del navegador, pero sin el inconveniente de almacenarla en el sistema del usuario. ;;Caso de negocio: membresía restringida del sitio web ;;Muchos sitios web imponen un muro de pago en torno a su contenido y mantienen listas de miembros propietarias para controlar el acceso a través de esto, lo que necesariamente también requiere sistemas de perfiles para permitir la personalización del usuario. Con uPass Connect, tanto el acceso a la membresía como los perfiles se pueden gestionar a través de los mecanismos estándar de uPass. ;;Caso de negocio: servicios embarazosos ;;Puede haber casos en los que la naturaleza del servicio al que se accede sea tal que un usuario de uPass no quiera que su foto se comparta con el servicio por razones bastante legítimas de vergüenza personal. ;;Con referencia a la Figura 2, el almacén seguro 24 es un almacén de datos seguro que preserva la privacidad y que contiene credenciales de usuario y metadatos relacionados. Uno de los objetivos del diseño del sistema es que un operador de uPass tenga el acceso mínimo a la información personal asociada con cualquier usuario de uPass. ;Si este almacén de datos se ve comprometido alguna vez, también lo están potencialmente las identidades de todos los usuarios. Por lo tanto, el almacenamiento seguro se coloca en un segmento de red interno separado y aislado del mundo exterior con múltiples capas de seguridad de hardware para garantizar esto. El enlace de datos entre el servicio de uPass y la tienda está protegido a nivel de protocolo para reducir aún más el riesgo de amenazas internas. ;Se contiene dentro del almacén de datos 24 (véanse las Figuras 3a/3b): ;los documentos de identidad registrados 10 para cada individuo; ;detalles de su dispositivo móvil autorizado 12a, 12b; ;credenciales actualmente emitidas 30; ;todas las credenciales emitidas anteriormente y ahora no válidas 30'; ;las declaraciones de identidad y sus anclajes de confianza 110; ;Perfiles de identidad 28a...2b. ;Este contenido se almacena de forma encriptada. ;Una base de datos cifrada también necesita una función de búsqueda y ésta se implementa en una realización al almacenar hashes criptográficos característicos para cada ítem de datos indexable. Tienen la ventaja de ser irreversibles, lo que hace que sea poco práctico utilizarlas como medio para recuperar los datos de fuente en caso de que el almacén seguro se vea comprometido, mientras que al mismo tiempo tienen una probabilidad muy baja de colisión, lo que las convierte en buenas claves de índice. ;Cada vez que se recibe una solicitud entrante de confirmación de identidad, el sistema de uPass primero verifica si el dispositivo está autorizado para realizar la solicitud. Si es así, luego se generarán recibos para ambas partes que se almacenan en los Libros de Recibos Maestros utilizando sus claves públicas proporcionadas. ;Base de datos de reconocimiento facial ;Para cada usuario, se mantiene una base de datos de reconocimiento facial separada entrenada en las fotos de ese usuario. ;Uso sin conexión ;El mecanismo estándar de uPass descrito anteriormente se basa en la disponibilidad de acceso a la red tanto para el portador de uPass como para el validador de uPass. ;Credenciales ;Una credencial de uPass es de un solo uso y requiere validación por el servicio de validación de uPass. Por lo tanto, las credenciales no se pueden utilizar de manera confiable para el uso sin conexión. ;Recibos ;Los recibos son identificadores publicados estáticamente que siempre se resuelven correctamente en un perfil publicado y en una credencial consumida. ;Muchos casos de uso sin conexión se pueden modelar en términos de una caché de recibos de transacciones implementada localmente. La base de datos local de recibos de transacciones es efectivamente una caché de identidad fuera de línea con validación visual del usuario respaldada por una foto para cada recibo. ;El identificador de transacción en el recibo nunca cambiará, por lo que se puede presentar como un código QR impreso, un código de barras o un blob binario en una etiqueta NFC. ;Es responsabilidad del validador de uPass asegurarse de que los datos de perfil relevantes se adquieran con éxito antes de que expiren sus ventanas de acceso, y que los ítems cargados se contabilicen correctamente durante el evento. ;El uso en base a recibos se puede conciliar más adelante a través de un mecanismo en línea para proporcionar una pista de auditoría concreta. ;Billetera electrónica ;Otra posible aplicación de uPass es una billetera digital que permite asociar una suma de dinero con un dispositivo particular y utilizarla para comprar bienes o servicios. Se trata esencialmente de una extensión del caso de uso de calificación que agrega un intercambio transaccional, que requiere la confirmación al proveedor de que un pago se ha realizado con éxito junto con la transferencia real de dinero entre las dos partes. ;;Valores de confianza: garantía ;;Una transacción se puede realizar con la intención particular de aumentar el valor de confianza asignado al perfil de una entidad objetivo, en el que una entidad de garantía responde por la entidad objetivo. La entidad de garantía recopila una credencial de la entidad objetivo y la presenta al sistema de uPass con su propia credencial en un mensaje de garantía electrónico. La credencial de la entidad de garantía está unida a un perfil de la entidad de garantía al que se asigna un valor de confianza relativamente alto (en relación con el perfil del objetivo unido a su credencial). En base a ese valor de confianza más alto, la transacción hace que se aumente el valor de confianza del perfil de la entidad objetivo. Al tratarse de una transacción, se utilizan las credenciales de un solo uso de la entidad de garantía y objetivo, y las credenciales nuevas, unidas a los perfiles respectivos, se emiten de acuerdo con lo anterior. ;;Cuando el perfil de la entidad objetivo se pone posteriormente a disposición de un validador a través de la presentación de la nueva credencial del objetivo, el sistema de uPass puede, además de revelar el valor de confianza (ahora más alto) del perfil relevante, identificar a la entidad de garantía como la fuente del valor de alta confianza para el validador. Por ejemplo, el validador puede ser una empresa, la entidad de garantía un cliente conocido de esa empresa y la entidad objetivo un nuevo cliente de esa empresa. El perfil puede ser un perfil creado específicamente para el beneficio de esa empresa, en el que el valor de confianza bajo inicial del perfil del objetivo es indicativo del hecho de que el objetivo es un cliente desconocido. ;;Casos de uso - figuras 11B-H ;;En cada uno de los casos de uso de las figuras 11B-H, un validador captura una credencial de un portador. En algunos casos el usuario es un portador y el validador un dispositivo, en otros viceversa. A veces ambos son humanos. Cada caso de uso se basa en una transacción de uPass, en la que el validador captura una credencial de portador 30 y la presenta al sistema de uPass con su(s) propia(s) credencial(es). Ambas credenciales son de un solo uso y están unidas a los perfiles de portador y validador respectivamente, que pueden ser perfiles creados específicamente para el tipo de transacción en cuestión. Sujeto a que ambas credenciales sean válidas, se publica una versión del perfil del validador (resp. del portador) y se proporciona un enlace para la versión publicada en un recibo enviado al portador (resp. del validador). Esto utiliza las credenciales, por lo que las credenciales nuevas del validador y del portador también se emiten en los recibos del validador y del portador, respectivamente. ;;Un usuario 20 puede verificar su identidad ante el propietario de un evento (fig. 11B) al mostrar una credencial 30 válida unida a, por ejemplo, un perfil específico del evento en la pantalla como un código QR. En este escenario, el usuario es el portador. La creación del perfil del evento puede estar condicionada a que el usuario haya pagado una cuota de admisión adecuada o algún otro criterio de admisión predeterminado. Un validador (propietario del evento) captura la credencial y la presenta al sistema de uPass. El sistema publica el perfil correspondiente para que sea accesible para el validador. El perfil puede ser simplemente una foto de la cara del usuario 20. El validador puede comparar la foto con el usuario y verificar de esta manera que el usuario 20 efectivamente tiene un perfil para el evento (porque coincide con la foto) y admitirlo en el evento. ;;Una credencial emitida por una página web (fig. 11c) en un dispositivo separado 1102 puede ser capturada por el dispositivo móvil 12 se puede utilizar para verificar simultáneamente el sitio web al usuario 20 del dispositivo 12 y el usuario al sitio web. En este escenario, el usuario es el validador y un servidor Web es el portador. El usuario desea iniciar sesión en un dispositivo separado y captura la credencial del sitio web 30 desde el dispositivo separado utilizando su dispositivo móvil 12. Es decir, la credencial se recibe en el dispositivo móvil 12 desde el servidor Web a través del dispositivo separado 1102. El usuario presenta su propia credencial y la credencial capturada al sistema de uPass. Sujeto a que ambos sean válidos, el sistema de uPass verifica al usuario en el servidor Web (al publicar el perfil relevante del usuario en una ubicación accesible para el servidor Web y enviar un recibo con un enlace a esa ubicación), y el servidor Web al usuario (al publicar el perfil relevante del servidor Web en una ubicación accesible para el dispositivo del usuario 12 y enviar un recibo con un enlace a esa ubicación). El sitio web puede conceder acceso al usuario de acuerdo con lo anterior, y el usuario puede proceder con la seguridad de que el sitio web es auténtico. Tanto el servidor Web como el usuario han agotado sus credenciales de un solo uso para sus respectivos perfiles, por lo que se emiten credenciales nuevas con los recibos. La Figura 11D muestra un escenario similar, en el que se accede directamente al sitio web desde el dispositivo móvil 12. En el presente documento, la credencial 30 (que no se muestra en la fig. 12D) llega directamente al dispositivo móvil 12 desde el servidor Web a través de Internet u otra red. Por lo demás, el mecanismo subyacente es el mismo. ;;La Figura 11E muestra cómo un usuario puede efectuar una compra de un sitio web alojado en un servidor Web presentado en un dispositivo separado con su dispositivo móvil 12. Después de capturar la credencial del sitio web, se requiere que el usuario proporcione una verificación adicional al ingresar un PIN o escanear su huella digital, por ejemplo, antes de que la aplicación de uPass presente la credencial capturada y la propia credencial del usuario al sistema de uPass para proporcionar seguridad adicional. Debido a que el sitio web confía en el sistema de uPass, permite que la transacción proceda en base al recibo que se le emite. La Figura 11F muestra un escenario equivalente en el que el sitio web se proporciona directamente al dispositivo móvil 12 y sin la capa adicional de seguridad. En ambas figuras 11E y 11F, un aspecto clave es la verificación simultánea del Servidor web al usuario (para que el usuario sepa que es seguro comprar bienes o servicios en el sitio web) y al usuario al servidor Web (para que el sitio web sepa que es seguro venderle al usuario). Como será evidente, un caso de uso equivalente es un caso de uso real en el que el servidor Web se sustituye por un proveedor humano que opera el dispositivo separado 1102. Las Figuras 11G (dispositivo separado) y 11F (mismo dispositivo 12) muestran cómo un usuario puede utilizar su uPAss para donar a organizaciones benéficas. Los principios subyacentes son los mismos que los escenarios de compra, solo que en el presente documento la recompensa obtenida por el usuario es intangible. ;;Transacciones - ejemplos ;;Una credencial unida a un perfil se puede utilizar una vez en una transacción de uPass para, por ejemplo, uno de los siguientes: ;;1. simplemente publicar ese perfil para que sea accesible a un validador; ;;2. modificar ese perfil, por ejemplo, al agregar a este uno(s) ítem(s) de datos; ;;3. crear un nuevo perfil; ;;el perfil al que está unida la credencial también se publica en 2 y 3, ya que es una parte inherente de una transacción de uPass. En 2 y 3, una entidad solicitante puede ser, por ejemplo, un empleador y una entidad objetivo un empleado (véase anteriormente), o la entidad solicitante puede ser parte del propio sistema de uPass, por ejemplo, el servicio de validación 14b o el controlador de uPass 116 - como excepción, la parte del sistema de uPass puede no tener un perfil o su propia credencial (aunque ninguno de los dos está excluido). Por lo tanto, en este caso, solo se puede publicar un perfil (el objetivo, enviado a la parte del sistema de uPass) y solo se puede generar una credencial nueva (para y enviar al objetivo). ;;Una transacción de uPass se puede realizar entre tres entidades (tal como el portador 20, el validador 52 y el servicio de validación (autenticador) 14b), como se muestra en la figura 12. En la figura 12 F representa una función a ejecutar. Se puede tratar de una simple validación. También puede ser una operación específica del almacén seguro 24 de acuerdo con lo expresado por una API pública. A representa una envoltura de autenticación para F. El portador 20 (por ejemplo, un cliente) envía su credencial Cc al validador 52 (por ejemplo, un comerciante) en un primer mensaje electrónico. El validador envía su propia credencial Cm con la credencial de portador Cc con un indicador de la función F a ejecutar al autenticador 14b en un segundo mensaje electrónico (“CmF(Cc)”). El autenticador envía CmF(Cc) con un indicador de la envoltura de autenticación A y su propia credencial Ca al almacén seguro 24. Se genera un conjunto de cuatro recibos R1, R2, R3, R4 ({Ri}). En el libro de recibos maestro 31 se almacena un recibo maestro para la transacción, y los recibos del portador/validador 32v/32b (R2/R3) se emiten al portador y al validador 20, 52. R1 se emite al autenticador 14b y R4 se registra en un registro de acceso seguro 1202. Todos los recibos R1, R2, R3, R4 y el recibo maestro comparten un identificador de transacción que los vincula a todos, ;;La Figura 13 muestra un escenario similar, sin embargo, en este caso el cliente se comunica directamente con el autenticador 14b y recibe ambos recibos R2, R3. ;;Biometría alternativa: ;;En otras realizaciones, se puede utilizar otro tipo de datos biométricos (distintos de, o además de, el selfie), tal como la imagen de una huella dactilar o una plantilla biométrica (por ejemplo, LBP) derivada de la misma. Para que esto sea efectivo, se necesita una imagen de alta resolución de la huella dactilar. Cuando la cámara del dispositivo no está equipada para proporcionar una imagen con la resolución necesaria, se pueden utilizar imágenes de superresolución, mediante las cuales se capturan múltiples imágenes de la huella dactilar y se combinan utilizando técnicas de superresolución conocidas para generar una imagen de huella dactilar compuesta que tiene una resolución de imagen mayor que cualquiera de las imágenes individuales. La imagen compuesta se genera preferiblemente en el dispositivo del usuario, aunque se puede implementar por el sistema de uPass. De acuerdo con lo anterior, cualquiera de las descripciones anteriores pertenecientes a una selfie se aplica igualmente a los datos de una imagen de huella dactilar (u otros datos biométricos). ;;Detección de vitalidad de la inscripción ;;En algunas realizaciones, durante el proceso de inscripción en el que se captura la imagen del pasaporte, esa misma imagen (o imágenes) se puede utilizar para la detección de vitalidad. Es decir, el sistema de uPass puede, al recibir una imagen de un documento de identidad, procesarla para verificar simultáneamente que el documento es auténtico y también que la mano que lo sostiene es una mano humana real (por ejemplo, en base al análisis de texturas). Es decir, la autenticación de documentos y la detección de vitalidad se pueden realizar en base a la(s) misma(s) imagen(es). La autenticidad del documento y la vitalidad de la mano que lo sostiene pueden ser requisitos previos para anclar el documento en el sistema. ;;Glosario ; ; (continuación) ; ; (continuación) ; ; (continuación) ; ;; Aspectos de la materia objeto y realizaciones de la misma ;A continuación se exponen diversos aspectos de la presente materia objeto, y sus realizaciones. ;Un aspecto se dirige a un método de autenticación de contenido ofrecido por una fuente de contenido a un dispositivo local para visualizar contenido, el método comprende: establecer una sesión de comunicación entre la fuente de contenido y un navegador que se ejecuta en el dispositivo local; transmitir desde la fuente de contenido al navegador una página de validación que comprende un token de autenticación de contenido que es una credencial de un solo uso generada aleatoriamente unida a la fuente de contenido; capturar el token de autenticación de contenido del navegador mediante una aplicación de verificación; transmitir el token de autenticación a un servicio de validación que determine si el token está unido a una fuente de contenido válida; y hacer que el contenido se visualice en el dispositivo local si el token está unido a una fuente de contenido válida. ;;En las realizaciones, hacer que se visualice el contenido puede comprender la transmisión de una recepción de fuente de contenido desde el servicio de validación a un dispositivo móvil con o que indica un ítem de datos relacionado con la fuente de contenido válida. La recepción de la fuente de contenido puede comprender un enlace que identifique una ubicación de memoria desde la que se puede acceder al ítem de datos, indicando de este modo el ítem de datos. Se puede acceder al ítem de datos desde un perfil digital de la fuente de contenido identificada por la credencial. El perfil se puede publicar al almacenar una versión del mismo en una ubicación de memoria direccionable, y se incluye un enlace que identifica la ubicación de memoria direccionable en el recibo de la fuente de contenido, indicando de este modo el ítem de datos. ;;La aplicación de verificación se puede ejecutar en el dispositivo móvil que captura el token de autenticación de contenido que se visualiza en la página de validación mediante uno de: captura de imagen digital; escaneo, comunicaciones de campo cercano y Bluetooth. ;;El token de autenticación de contenido se puede recibir por un navegador local del dispositivo local y transferir a la aplicación de verificación que se ejecuta en el dispositivo local. ;;Hacer que se visualice el contenido puede incluir la transmisión de un recibo al dispositivo local que indique un ítem de datos relacionado con la fuente válida del contenido. ;;El token puede identificar una dirección de la fuente del contenido, el método puede comprender transmitir la dirección a un servicio de verificación de direcciones para confirmar que la dirección es una dirección válida. ;;El ítem de datos se puede visualizar en el dispositivo móvil. ;;El ítem de datos puede ser detalles de un servidor que aloja el contenido. El ítem de datos puede comprender detalles de un dispositivo virtual que aloja el contenido y/o un dispositivo físico en el que se ejecuta el dispositivo virtual. ;El método puede comprender las etapas de transmisión desde el dispositivo móvil de un token de autenticación de dispositivo, que es una credencial de un solo uso generada aleatoriamente unida al dispositivo móvil al servicio de verificación con el token de autenticación de contenido. ;;El servicio de validación puede utilizar el token de autenticación del dispositivo para acceder a un perfil de identidad digital utilizando la credencial. El servicio de validación puede generar un recibo de identificación de dispositivo que comprende o que indique un ítem de datos al que se accede desde el perfil de identidad digital y transmitir el recibo a la fuente de contenido. La fuente de contenido puede determinar si se publica o no contenido en base al ítem de datos en el recibo de identificación del dispositivo. El método puede comprender en la transmisión en el recibo de identificación del dispositivo de un nuevo token de autenticación del dispositivo. ;;El método puede comprender un token de autenticación de contenido nuevo para la fuente de contenido. ;;El recibo de identificación del dispositivo y el recibo de fuente de contenido pueden compartir un identificador de transacción común. ;;El método puede comprender las etapas de transmisión desde el dispositivo local un token de autenticación, que es una credencial de un solo uso generada aleatoriamente unida al dispositivo local al servicio de verificación con el token de autenticación de contenido. ;;La fuente del contenido puede comprender un servidor y el token se puede unir al servidor. La fuente de contenido puede comprender un servidor y el token de autenticación de contenido se puede unir a un dispositivo virtual transitorio creado por el servidor en un procedimiento de establecimiento de sesión instigado por el dispositivo local. ;;Un valor de confianza se puede asociar con el ítem de datos y visualizar con el ítem de datos. ;;Otro aspecto se dirige a un sistema informático que comprende: ;;un sistema de identidad digital configurado para implementar un servicio de validación; ;;un dispositivo local que comprende una interfaz de red y un procesador configurado para ejecutar un navegador que opera para: ;establecer una sesión de comunicación entre una fuente de contenido y el navegador a través de la interfaz de red, y recibir desde la fuente de contenido una página de validación que comprende un token de autenticación de contenido que es una credencial de un solo uso generada aleatoriamente unida a la fuente de contenido; ;en el que una aplicación de verificación captura el token de autenticación de contenido del navegador y transmite el token de autenticación a un servicio de validación que determina si el token está unido a una fuente de contenido válida; y ;en el que el servicio de validación hace que el contenido se visualice en el dispositivo local si el token está unido a una fuente de contenido válida. ;En las realizaciones, la aplicación de verificación se puede ejecutar en el dispositivo informático local. El sistema informático puede comprender un dispositivo móvil, que comprende un procesador y una interfaz de red, en la que la aplicación de verificación se ejecuta en el procesador del dispositivo móvil. ;Otro aspecto se dirige a un sistema de identidad digital para crear una identidad digital almacenada por ordenador que comprende: ;una interfaz de red configurada para enviar y recibir mensajes electrónicos; ;almacenamiento electrónico persistente; ;un módulo de gestión de perfiles configurado para recibir desde una entidad un mensaje electrónico que comprende un ítem de datos, extraer el ítem de datos desde el mensaje electrónico y almacenar el ítem de datos en un perfil digital en el almacenamiento electrónico persistente; ;un módulo de creación de credenciales configurado para generar una credencial para el perfil y asociar la credencial con el perfil digital; ;un módulo de generación de recibos configurado para generar automáticamente dos recibos no coincidentes, cada recibo que comprende un identificador de transacción, un primero de los recibos que comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil, un segundo de los recibos que comprende la credencial, en el que el primer recibo se almacena en el sistema de identidad digital y el segundo recibo se transmite a una dirección asociada con la entidad; y ;un módulo de publicación configurado para publicar el perfil al almacenar una versión del mismo en una ubicación de memoria direccionable; ;En las realizaciones, también se puede generar un recibo maestro que comprende datos de cada recibo y almacenarlo en un libro de recibos maestro en el sistema de identidad digital, mediante el cual tanto el primer recibo como el recibo maestro se almacenan en el sistema de identidad digital. El recibo maestro puede comprender solo una parte del primer recibo. El recibo maestro puede contener el enlace pero no la credencial. Por ejemplo, el recibo maestro puede comprender el enlace y el identificador de transacción, pero no la credencial. Alternativamente, los datos de cada recibo en el recibo maestro se pueden cifrar con el identificador de transacción, en el que el recibo maestro no incluye el identificador de transacción. ;La credencial puede ser una credencial aleatoria de un solo uso. ;Se pueden crear múltiples perfiles digitales asociados con la entidad, cada uno de los cuales se asocia con una credencial única para ese perfil, en el que cada perfil digital se puede publicar al asignar un conjunto único de ítems de datos para cada perfil digital a la ubicación de memoria direccionable correspondiente. ;El ítem de datos se puede compartir entre los conjuntos únicos. Por ejemplo, uno de los conjuntos puede consistir solo del ítem de datos, y los conjuntos restantes pueden comprender cada uno el ítem de datos y al menos un ítem de datos adicional. ;El ítem de datos puede ser una imagen visual de la entidad. ;Los múltiples ítems de datos se pueden recibir en el mensaje electrónico y almacenar en el perfil. ;Los metadatos disponibles desde un dispositivo informático asociado con la entidad se pueden recibir con el ítem de datos y almacenar en el sistema de identificación digital. La credencial se puede generar utilizando los metadatos. Por ejemplo, la credencial puede ser generada por un hash de los metadatos y una sal aleatoria. La sal aleatoria se puede almacenar en asociación con los metadatos, por lo que se puede generar una copia de la credencial a partir de la sal aleatoria almacenada y los metadatos almacenados. La credencial se puede generar mediante el hash de los metadatos del dispositivo y la sal aleatoria un número aleatorio de veces, en el que el número aleatorio se puede almacenar en asociación con la sal aleatoria y los metadatos. Los metadatos pueden comprender en un identificador del dispositivo informático (identificador de dispositivo). ;La credencial se puede asociar con el perfil digital al crear una entrada en una base de datos, la entrada que comprende el perfil digital o un indicador permite ubicar el perfil digital en el almacenamiento electrónico persistente, en el que el módulo de publicación se puede configurar para utilizar la credencial como clave para esa entrada en la base de datos para acceder al perfil para publicación. ;El perfil se puede publicar en respuesta a la credencial que se presenta al sistema de identidad digital. La credencial es presentada por una entidad validadora distinta de la entidad, que ha sido la credencial proporcionada a la entidad validadora por la entidad. ;La credencial puede ser de un solo uso, y el módulo de creación de credencial se puede configurar para generar una credencial nueva en respuesta a la credencial que se presenta al sistema de identidad digital, mediante la cual el módulo de publicación publica otra versión del perfil en una ubicación de memoria direccionable diferente en respuesta a la nueva credencial que se presenta al sistema de identidad digital. ;Un identificador de dispositivo se puede recibir con el ítem de datos y almacenar en el sistema de identificación digital, en el que la publicación del perfil puede estar condicionada a que se presente un identificador de dispositivo coincidente con la credencial. ;El enlace se puede generar a partir de y/o la ubicación de la memoria se puede seleccionar en base a una secuencia generada aleatoriamente. ;El enlace puede ser un Indicador Uniforme de Recursos (URI). ;El sistema de identidad digital puede comprender un módulo de gestión del valor de confianza configurado para asignar un valor de confianza al perfil en base a al menos una de las fuentes del mensaje electrónico y un tipo de ítem de datos. El valor de confianza se puede publicar con el perfil, por lo que el valor de confianza y el perfil están disponibles para una entidad solicitante. ;El valor de confianza se puede cambiar con el tiempo en base a una señal de reloj. ;Otro aspecto se refiere a un método implementado por ordenador para crear una identidad digital almacenada por ordenador que comprende: ;recibir desde una entidad un mensaje electrónico que comprende un ítem de datos; ;extraer el ítem de datos desde el mensaje electrónico; ;almacenar el ítem de datos en un perfil digital en el almacenamiento electrónico persistente; ;generar una credencial para el perfil y asociar la credencial con el perfil digital; ;generar automáticamente dos recibos no coincidentes, cada recibo comprende un identificador de transacción, un primero de los recibos que comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil, un segundo de los recibos que comprende la credencial; ;almacenar el primer recibo en el sistema de identidad digital; y ;transmitir el segundo recibo a una dirección asociada con la entidad; y ;publicar el perfil al almacenar una versión del mismo en una ubicación de memoria direccionable. ;Otro aspecto se dirige a un método de registro de una identidad digital que comprende: ;capturar en un dispositivo informático un dato asociado con una entidad; ;crear un mensaje electrónico que comprende el ítem de datos; ;transmitir el mensaje electrónico a un servicio de registro; ;recibir un recibo desde el servicio de registro; ;extraer una credencial del recibo para que la credencial esté disponible para acceder al ítem de datos para autenticar la entidad; y ;almacenar el recibo en un libro de recibos local en un lugar accesible para el dispositivo informático. ;En las realizaciones, el ítem de datos se puede capturar en forma de un dato de identificación de un documento de identidad. ;El ítem de datos se puede capturar en forma de una foto tomada por una cámara del dispositivo informático. ;El primer ítem de datos se puede capturar por uno de los siguientes métodos: escaneo, acceso de campo cercano; y Bluetooth. ;El libro de recibos local se puede mantener en un servidor accesible para el dispositivo. ;Otro aspecto se dirige a un método implementado al ejecutar un software de identidad digital en un procesador de un dispositivo de usuario para: ;capturar con una cámara del dispositivo del usuario una imagen de la cara de un usuario del dispositivo; capturar datos de un documento de identidad del mundo real, los datos incluyen una fotografía de identificación, en la que los datos se capturan con la cámara, desde un transmisor electrónico integrado en el documento de anclaje, o una combinación de ambos; ;transmitir la imagen del usuario y los datos capturados a un sistema de identificación digital; y ;recibir desde el sistema de identificación digital una credencial para el usuario, en la que la presentación de la credencial al sistema de identidad digital hace que al menos parte de los datos capturados estén disponibles para una entidad presentadora. ;En las realizaciones, los datos capturados también pueden comprender un atributo del documento, ;El documento de identidad puede ser un pasaporte o una licencia de conducción. ;El dispositivo del usuario puede ser un dispositivo inteligente, tal como un teléfono inteligente o un ordenador tipo tableta. ;Otro aspecto está dirigido a un dispositivo de usuario que comprende: ;una cámara; ;un procesador configurado para ejecutar software de identidad digital que opera para: ;capturar con la cámara del dispositivo del usuario una imagen de la cara de un usuario del dispositivo; capturar datos de un documento de identidad del mundo real, los datos incluyen una fotografía de identificación, en la que los datos se capturan con la cámara, desde un transmisor electrónico integrado en el documento de anclaje, o una combinación de ambos; ;transmitir la imagen del usuario y los datos capturados a un sistema de identificación digital; y ;recibir desde el sistema de identificación digital una credencial para el usuario, en la que la presentación de la credencial al sistema de identidad digital hace que al menos parte de los datos capturados estén disponibles para una entidad presentadora. ;Otro aspecto se refiere a un método implementado por ordenador por un sistema de identidad digital, el método comprende: ;recibir en un mensaje electrónico desde un dispositivo de usuario: una imagen de la cara de un usuario del dispositivo de usuario que se ha capturado en el dispositivo de usuario; y los datos que se han capturado de un documento de identidad del mundo real y que comprenden una fotografía de identificación; ;almacenar al menos parte de los datos capturados en el sistema de identidad digital en el almacenamiento electrónico persistente; ;comparar la imagen de la cara con la fotografía de identidad utilizando un algoritmo de verificación facial; y solo si la imagen de la cara coincide con la fotografía de identificación, generar una credencial para el usuario y al transmitir la credencial al usuario, en el que la presentación de la credencial al sistema de identidad digital hace que al menos parte de los datos almacenados estén disponibles para una entidad presentadora. ;En las realizaciones, se puede recibir un atributo del documento en el mensaje, y la credencial se puede generar y transmitirse solo si el atributo cumple con un criterio predeterminado. La fotografía y/o imagen puede estar disponible para la entidad presentadora. ;Otro aspecto se dirige a un sistema de identidad digital que comprende: ;una interfaz de red configurada para enviar y recibir mensajes electrónicos; ;un procesador configurado para realizar operaciones que comprenden: ;recibir en un mensaje electrónico desde un dispositivo de usuario: una imagen de la cara de un usuario del dispositivo de usuario que se ha capturado en el dispositivo de usuario; y los datos que se han capturado de un documento de identidad del mundo real y que comprenden una fotografía de identificación; ;almacenar al menos parte de los datos capturados en el sistema de identidad digital en el almacenamiento electrónico persistente; ;comparar la imagen de la cara con la fotografía de identidad mediante un algoritmo de verificación facial; ;solo si la imagen de la cara coincide con la fotografía de identificación, generar una credencial para el usuario; y transmitir la credencial al usuario, en la que la presentación de la credencial al sistema de identidad digital hace que al menos una parte de los datos almacenados estén disponibles para una entidad presentadora. ;Otro aspecto se dirige a un método de autenticación de una credencial digital de un portador por un dispositivo validador, el método comprende: ;capturar la credencial al portador por el dispositivo validador; ;transmitir a un servicio de validación la credencial de portador con una credencial de validador unida al dispositivo de validación; ;en el servicio de validación, validar la credencial de portador y la credencial de validación, y si la credencial de validador es válida, utilizar la credencial de portador para acceder a un ítem de datos de un perfil digital y crear un mensaje electrónico para transmisión al dispositivo de validación, el mensaje electrónico que indica el ítem de datos y que comprende una nueva credencial de validador generada por el servicio de validación; ;emitir una nueva credencial de portador y crear un mensaje electrónico para transmitir la nueva credencial de portador a una dirección asociada con el portador. ;En las realizaciones, el método puede comprender la etapa de utilizar la credencial del validador para acceder a un ítem de datos de un perfil digital asociado con el dispositivo de validación y crear un mensaje electrónico para transmisión al portador, el mensaje electrónico que indica un ítem de datos para verificación por el portador. ;El mensaje electrónico puede indicar el ítem de datos al proporcionar un enlace a una versión del perfil digital que se encuentra en una ubicación de memoria direccionable identificada en el enlace. ;El mensaje electrónico que indica el ítem de datos para verificación por el portador puede indicar el ítem de datos al proporcionar un enlace a una versión del perfil digital asociado con el validador en una ubicación de memoria direccionable indicada por el enlace. ;El ítem de datos puede comprender una imagen visual del portador o del validador, respectivamente. ;La nueva credencial de portador se puede generar para transmisión al portador y está comprendida en un recibo que tiene un identificador de transacción. El servicio de validación puede generar un recibo maestro, en el que el recibo maestro se puede almacenar en un libro de recibos maestro. El servicio de validación puede generar un recibo maestro que tiene el mismo identificador de transacción que el recibo generado para transmisión al portador, en el que el recibo maestro se puede almacenar en un libro de recibos maestro. Alternativamente, parte del recibo maestro se puede cifrar con el identificador de transacción, en cuyo caso el identificador de transacción no se incluye en el recibo maestro. ;La nueva credencial de validador puede estar comprendida en un recibo que no coincide que tiene el mismo identificador de transición. ;La dirección asociada con el portador puede comprender una dirección de un dispositivo previamente registrado por el portador y almacenado en asociación con la credencial del portador. ;La etapa de generar una nueva credencial puede comprender utilizar una secuencia generada aleatoriamente para generar una nueva credencial unida al perfil digital. ;Las credenciales pueden ser de un solo uso. ;Otro aspecto se refiere a un método de proporcionar acceso a los perfiles digitales almacenados electrónicamente en un sistema de identidad digital, el método comprende: ;recibir desde una entidad solicitante un mensaje de solicitud electrónica que identifique a una entidad objetivo; en respuesta a la solicitud, publicar: (i) un perfil digital de la entidad objetivo al almacenar una versión de ese perfil en una ubicación de memoria direccionable, y (ii) un perfil digital de la entidad solicitante al almacenar una versión de ese perfil en otra ubicación de memoria direccionable; ;generar dos recibos no coincidentes, cada uno de los cuales comprende un identificador de transacción, el primero de los cuales comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil de la entidad objetivo, el segundo de los cuales comprende un enlace que identifica la otra ubicación de memoria en la que se publica el perfil de la entidad solicitante; ;;transmitir el primer recibo a una dirección asociada con la entidad solicitante; y ;;transmitir el segundo recibo a una dirección asociada con la entidad objetivo. ;;En las realizaciones, una credencial objetivo se puede asociar con el perfil de la entidad objetivo y una credencial de solicitante se puede asociar con el perfil de la entidad solicitante en una base de datos del sistema de identidad digital, y la etapa de publicación puede estar condicionada a que coincidan las credenciales objetivo y solicitante que se reciben en el mensaje de solicitud electrónica. ;;Las credenciales pueden ser de un solo uso, y el método puede comprender la generación de un nuevo destino y una nueva credencial de solicitante y asociarlas con el perfil de la entidad objetivo y el perfil de la entidad solicitante en la base de datos, respectivamente, las credenciales objetivo y solicitante nuevas se incluyen en el segundo y primer recibo, respectivamente. ;;El método puede consistir en el almacenamiento de un recibo maestro en el sistema de identidad digital, el recibo maestro comprende datos de ambos recibos y se almacena en un libro de recibos maestro. ;;Los recibos maestros pueden comprender ambos enlaces, pero es posible que no incluyan las credenciales nuevas. Los datos de ambos recibos en el recibo maestro (por ejemplo, los enlaces) se pueden cifrar con el identificador de transacción, en cuyo caso el identificador de transacción no se incluye en el recibo maestro. ;;El recibo maestro puede comprender ambos enlaces y el identificador de transacción, pero no puede incluir las credenciales nuevas. ;;La entidad objetivo puede ser un portador y la entidad solicitante un validador, el perfil del portador es un perfil digital preexistente al que se accede en el almacenamiento electrónico persistente en respuesta a la solicitud. ;;La entidad objetivo puede ser un registrante y la entidad solicitante puede ser un módulo de inscripción del sistema de identidad digital que haya creado el perfil digital en el almacenamiento electrónico persistente. ;;Se puede asignar un valor de confianza respectivo a cada perfil que se publique con ese perfil y al que se pueda acceder a través del enlace correspondiente. ;;Otro aspecto se refiere a un sistema informático que comprende una interfaz de red configurada para transmitir y recibir mensajes electrónicos, y un procesador configurado para aplicar el método de cualquier reivindicación anterior. ;Otro aspecto se dirige a un sistema de identidad digital que comprende: ;;una interfaz de red configurada para enviar y recibir mensajes electrónicos; ;;almacenamiento electrónico persistente que contiene un perfil digital de una entidad objetivo y un perfil digital de la entidad solicitante; ;;un módulo de publicación configurado para recibir desde la entidad solicitante un mensaje de solicitud electrónica que identifique a la entidad objetivo y, en respuesta a la solicitud, publicar: (i) el perfil digital de la entidad objetivo al almacenar una versión de ese perfil en una ubicación de memoria direccionable, y (ii) el perfil digital de la entidad solicitante al almacenar una versión de ese perfil en otra ubicación de memoria direccionable; ;;un módulo de generación de recibos configurado para generar dos recibos no coincidentes, cada uno de los cuales comprende un identificador de transacción, el primero de los cuales comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil de la entidad objetivo, el segundo de los cuales comprende un enlace que identifica la otra ubicación de memoria en la que se publica el perfil de la entidad solicitante, en el que el primer recibo se transmite a una dirección asociada con la entidad solicitante y el segundo recibo se transmite a una dirección asociada con la entidad objetivo. ;;Otro aspecto se dirige a un sistema de identidad digital que comprende: ;;un módulo de inscripción configurado para recibir un ítem de datos desde un dispositivo de inscripción y para crear en el almacenamiento electrónico persistente un perfil digital que comprende el ítem de datos; ;;un módulo de creación de credenciales configurado para generar una credencial a partir de una secuencia aleatoria, para asociar la credencial con el perfil digital en una base de datos y para transmitir la credencial al dispositivo de inscripción; ;un módulo de publicación configurado, en respuesta a la presentación posterior de la credencial al sistema de identidad digital, para publicar el perfil digital al almacenar una versión del perfil digital en una ubicación de memoria accesible para un dispositivo que presente la credencial. ;En las realizaciones, el módulo de inscripción se puede configurar para recibir también metadatos del dispositivo de inscripción, que se almacena en la base de datos en asociación con el perfil. ;La credencial se puede generar a partir de la secuencia aleatoria y los metadatos, y la credencial se puede asociar con el perfil al almacenar la secuencia aleatoria y los metadatos en la base de datos en asociación con el perfil, y en el que el sistema puede comprender un módulo de validación configurado para generar una copia de la credencial a partir de la secuencia y los metadatos almacenados en la base de datos, y la publicación del perfil puede estar condicionada a que la credencial presentada coincida con la copia. ;Los metadatos pueden comprender un identificador del dispositivo de inscripción, y la publicación del perfil también puede estar condicionada a que se presente un identificador de dispositivo coincidente con la credencial, por lo que el uso de la credencial se restringe al dispositivo de inscripción. ;La credencial se puede asociar con el perfil al almacenar una copia de la credencial en la base de datos en asociación con el perfil, en la que el sistema puede comprender un módulo de validación configurado para validar la credencial presentada al compararla con la copia y la publicación del perfil puede estar condicionada a que la credencial presentada sea válida. ;Un enlace que identifica la ubicación de la memoria direccionable se puede transmitir al dispositivo presentador. El enlace se puede generar a partir de una secuencia aleatoria. La ubicación de la memoria direccionable se puede seleccionar en base a una secuencia aleatoria. ;Otro aspecto se dirige a un sistema de identidad digital de acuerdo con la reivindicación 1, en el que el almacenamiento electrónico persistente también contiene otro perfil digital asociado con otra credencial y que comprende un ítem de datos que se ha recibido del dispositivo presentador, en el que ambas credenciales son presentadas por el dispositivo presentador y, en respuesta, el otro perfil se publica en una ubicación de memoria diferente accesible para el dispositivo de inscripción. ;En las realizaciones, el sistema de identidad digital puede comprender un módulo de generación de recibos configurado para generar dos recibos no coincidentes, uno de los cuales se transmite al dispositivo presentador y comprende un enlace que identifica la ubicación de memoria en la que se publica el perfil, el otro de los cuales se transmite al dispositivo de inscripción y comprende un enlace que identifica la otra ubicación de memoria en la que se publica el otro perfil. ;El sistema de identidad digital de acuerdo con puede comprender un módulo de asignación de valores de confianza configurado para asignar un valor de confianza al perfil en base a al menos uno de los siguientes ítems: un tipo de ítem de datos recibido y una fuente del ítem de datos. ;Otro aspecto se dirige a un método implementado en un sistema de identidad digital y que comprende: ;recibir un ítem de datos desde un dispositivo de inscripción; ;crear en el almacenamiento electrónico persistente un perfil digital que comprende los ítems de datos; ;generar una credencial a partir de una secuencia aleatoria; ;asociar la credencial con el perfil digital en una base de datos; ;transmitir la credencial al dispositivo de inscripción, en la que la presentación posterior de la credencial al sistema de identidad digital provoca la publicación del perfil digital al almacenar una versión del perfil digital en una ubicación de memoria accesible para un dispositivo que presenta la credencial. ;Otro aspecto se refiere a un método de proporcionar acceso a un perfil digital que comprende: ;recibir una credencial de un solo uso asociada con un perfil digital en el almacenamiento electrónico persistente; validar la credencial y, solo si la credencial es válida, publicar el perfil en una ubicación de memoria direccionable al almacenar una versión de la misma en la ubicación de memoria, invalidando de este modo la credencial; generar una nueva credencial de un solo uso para el perfil digital; ;asociar la nueva credencial con el perfil digital; y ;transmitir la credencial nueva a una dirección asociada con una entidad, mediante la cual la entidad puede utilizar la credencial nueva una vez a partir de entonces para hacer que el perfil se vuelva a publicar en una ubicación de memoria direccionable diferente. ;Otro aspecto se dirige a un sistema informático que comprende una interfaz de red y un procesador configurado para implementar el método. ;Otro aspecto se dirige a un sistema informático que comprende: ;almacenamiento electrónico; ;una interfaz de red configurada para recibir mensajes electrónicos; ;un procesador configurado para ejecutar un código de gestión de identidad que opera para: ;recibir un mensaje electrónico desde la interfaz de red, el mensaje que incluye al menos un ítem de datos que se incluirá en un perfil digital para una entidad, el ítem de datos asociado con la entidad y que identifica de manera única a la entidad; ;extraer el ítem de datos del mensaje electrónico; ;crear un perfil digital utilizando el ítem de datos en el almacenamiento electrónico, en el que el perfil comprende el ítem de datos; ;asignar un valor de confianza al perfil, en el que el valor de confianza se asigna en base a al menos una de las fuentes del mensaje electrónico y un tipo de ítem de datos; y ;crear y transmitir una credencial a la entidad, en la que la presentación de la credencial al sistema informático hace que una versión del perfil digital y el valor de confianza estén disponibles para una entidad presentadora. ;En las realizaciones, lo electrónico puede contener una pluralidad de perfiles digitales asociados con la entidad, cada perfil digital comprende un conjunto único de ítems de datos para ese perfil digital. Al menos algunos de los ítems de datos se pueden compartir entre los conjuntos únicos. ;En las realizaciones, el almacenamiento electrónico puede contener documentos de anclaje en asociación con los perfiles digitales, en los que se puede recibir un documento de anclaje en el mensaje electrónico y el ítem de datos se ha extraído del documento de anclaje. ;El valor de confianza se puede asignar en base al tipo y/o la antigüedad del documento de anclaje. ;El valor de confianza se puede asignar en base a la fuente del documento de anclaje. ;La versión del perfil puede estar disponible al almacenarla en una ubicación de memoria direccionable y al transmitir un enlace que identifique la ubicación de memoria a la entidad presentadora. ;El procesador se puede configurar para crear y transmitir una credencial cada vez que se almacena un ítem de datos en un perfil digital, en el que la presentación de cada credencial al sistema informático puede hacer que una versión respectiva de la misma se almacene en una ubicación de memoria direccionable diferente, por lo que se pueden publicar múltiples versiones del perfil. ;La ubicación de la memoria se puede seleccionar en base a una secuencia aleatoria. El enlace de enlace se generará a partir de una secuencia aleatoria. ;El enlace puede ser un Indicador Uniforme de Recursos. ;Uno de los ítems de datos puede ser una imagen visual de la entidad. ;La entidad puede ser una persona y la imagen visual es una imagen facial de la persona. ;El almacenamiento electrónico puede comprender una sección de almacenamiento de metadatos del dispositivo que contiene metadatos asociados con dispositivos informáticos que se han utilizado para transmitir mensajes electrónicos a la interfaz de red. ;El almacenamiento electrónico puede contener uno o más perfiles digitales para cada una de las múltiples entidades. El perfil digital puede comprender múltiples ítems de datos recibidos desde la entidad. ;El código de gestión de identidad puede ser operable para asignar un valor de confianza asociado a una fuente del mensaje electrónico, de tal manera que cuando la fuente del mensaje electrónico es desconocida para el sistema informático, el valor de confianza es bajo. ;Cuando el sistema informático conozca la fuente del mensaje electrónico, el código de gestión de la identidad podrá ser operable para asignar un valor de confianza adecuado al estado de la fuente del mensaje electrónico. ;Cuando la fuente del mensaje electrónico es una autoridad emisión de documentos, el valor de confianza que se asigna puede ser elevado. ;El código de gestión de identidad puede ser operable para asignar un valor de confianza de tal manera que cuando una de las múltiples entidades que tienen un perfil digital en el almacenamiento electrónico es la fuente del mensaje electrónico, se utiliza un valor de fiabilidad contingente asociado a esa entidad para calcular el valor de confianza. El valor de fiabilidad contingente puede depender del uso del perfil digital por parte de las múltiples entidades en uno o más procesos de autenticación. ;El código de gestión de identidades puede ser operable para actualizar el perfil digital al recibir más ítems de datos, y en el que el valor de confianza asignado cambia cuando se actualiza el perfil. ;El procesador se puede configurar para cambiar el valor de confianza asignado a lo largo del tiempo en base a una señal de reloj. ;El valor de confianza se puede incrementar en respuesta a la recepción de una imagen visual adicional de la entidad. Es posible que se requiera que la entidad presente un nuevo ítem de datos al iniciar sesión posteriormente en el sistema, y el valor de confianza puede cambiar en base al nuevo ítem de datos. ;El nuevo ítem de datos puede ser una imagen visual de la entidad. ;El código de gestión de identidad puede ser operable para recibir un ítem de datos desde un tercero para asignar un perfil a la entidad, y en el que el valor de confianza que se asigna puede depender del estado del tercero. ;El mensaje electrónico se puede recibir desde la entidad. ;El mensaje electrónico se puede recibir desde otra entidad distinta a la entidad. ;El ítem de datos puede ser uno de los dos ítems de datos que se reciben en el mensaje, el primero de los cuales es una imagen de la entidad que se ha capturado con una cámara y el segundo de los cuales es una fotografía de identificación que se ha capturado de un documento de identidad del mundo real, y el valor de confianza se puede asignar al comparar los dos ítems de datos y puede reflejar hasta qué punto coinciden, Los dos ítems de datos se pueden comparar utilizando un algoritmo de verificación facial. ;Otro aspecto se refiere a un método implementado por ordenador para gestionar un perfil digital que comprende: recibir un mensaje electrónico que incluya al menos un ítem de datos que se incluirá en un perfil digital de una entidad, el ítem de datos asociado a la entidad y que identifique de forma única a la entidad; ;extraer el ítem de datos del mensaje electrónico; ;crear un perfil digital utilizando el ítem de datos en el almacenamiento electrónico, en el que el perfil comprende el ítem de datos; ;asignar un valor de confianza al perfil, en el que el valor de confianza se asigna en base a al menos una de las fuentes del mensaje electrónico y el tipo del ítem de datos; y ;crear y transmitir una credencial a la entidad, en la que la presentación de la credencial al sistema informático hace que una versión del perfil digital y el valor de confianza estén disponibles para la entidad presentadora. ;Otro aspecto de la presente invención se dirige a un sistema de identidad digital que comprende un almacén de datos que tiene al menos una ubicación de almacenamiento, en la que se mantienen los datos de identidad de una entidad; una interfaz de ordenador configurada para recibir un mensaje electrónico, que identifica la ubicación de almacenamiento de los datos de identidad de la entidad en el almacén de datos, en el que el mensaje comprende una credencial de un solo uso de la entidad; y un sistema informático configurado para validar la credencial y, si la credencial es válida, recuperar los datos de identidad desde la entidad de la ubicación de almacenamiento identificada, emitir una nueva credencial de un solo uso para la entidad y publicar los datos de identidad recuperados al almacenar una versión de la misma en una ubicación de memoria direccionable; en la que el sistema informático se configura para generar en un almacén de recibos maestro un recibo maestro, en el que el recibo maestro comprende un enlace para la ubicación de memoria direccionable y un índice que comprende un hash de la credencial nueva. ;En las realizaciones, la recepción maestra también puede comprender un hash de la credencial recibida en el mensaje electrónico. ;El sistema informático se puede configurar para proporcionar a otra entidad, en respuesta a recibir una concesión de acceso por parte de la entidad a la otra segunda entidad, un recibo que comprende una copia del enlace mediante el cual la otra entidad pueda acceder a los datos de identidad publicados de la entidad. ;El recibo puede comprender un identificador de transacción, en el que el enlace en el recibo maestro y/o los datos de identidad publicados en la ubicación de memoria direccionable se cifran con el identificador de transacción. ;El sistema informático se puede configurar para proporcionar el recibo a la otra entidad solo si ha recibido una credencial válida de un solo uso de la otra entidad en asociación con la concesión de acceso, en la que en ese evento el sistema informático emite una nueva credencial de un solo uso a la otra entidad, en la que el recibo maestro comprende otro índice que comprende un hash de la nueva credencial emitida a la otra entidad. ;El sistema informático se puede configurar para proporcionar a la entidad otro recibo que comprende el mismo identificador de transacción. ;La concesión de acceso podrá ser denotada por el mensaje electrónico que comprende la credencial de la entidad. El mensaje electrónico que comprende la credencial de la entidad se puede recibir desde la entidad. ;El mensaje electrónico que comprende la credencial de la entidad se puede recibir desde la otra entidad. ;En respuesta a recibir una copia de la credencial en un momento posterior en un mensaje de solicitud de búsqueda electrónica a través de la interfaz de ordenador, el sistema informático se puede configurar para generar un índice de búsqueda que comprende un hash de la credencial recibida en el mensaje de solicitud de búsqueda, utilizar el índice de búsqueda para ubicar el recibo maestro en el recibo maestro. ;El sistema informático se puede configurar para generar un índice de búsqueda que comprende un hash de la credencial recibida en el mensaje electrónico, utilizar el índice de búsqueda para ubicar en el almacén de recibos maestros un recibo maestro anterior que tenga un índice que coincida con el índice de búsqueda, y generar un hash y/o una firma digital a partir de al menos parte del recibo maestro anterior, en el que el recibo maestro también comprende el hash de al menos una parte del recibo maestro anterior. ;El hash y/o la firma digital se pueden generar a partir de prácticamente la totalidad del recibo maestro anterior, que incluye su índice. ;La otra entidad puede tener una clave simétrica o privada, y el sistema informático se puede configurar para cifrar el otro recibo utilizando una versión de la clave privada o una clave pública correspondiente disponible en el sistema de identidad digital. ;La entidad puede tener una clave simétrica o privada, y el sistema informático se puede configurar para cifrar el otro recibo utilizando una versión de la clave privada o una clave pública correspondiente disponible en el sistema de identidad digital. ;El hash de la credencial en el recibo maestro se puede cifrar con el identificador de transacción. ;Otro aspecto se dirige a un método que comprende la implementación de cualquiera de los sistemas, dispositivos, aplicaciones u otras funcionalidades descritas anteriormente. ;Otro aspecto está dirigido a un producto de programa informático que comprende un código almacenado en un medio de almacenamiento legible por ordenador y configurado para implementar cualquier método, sistema o funcionalidad del dispositivo divulgado en el presente documento. ;El sistema y método descrito anteriormente puede, en las realizaciones, ser utilizado para cualquiera de los siguientes. Tenga en cuenta que el “sistema de uPass” a veces se denomina en el presente documento un “sistema YOTI”. Los términos “uPass” y “YOTIVYoti” se utilizan indistintamente en esta divulgación. ;uPass Connect ;El mecanismo uPass Connect se puede utilizar para los siguientes fines: ;• Verificar la identidad (ID) En Línea ;• Verificar la edad en línea ;• Mecanismos KYC (Conoce a Tu Cliente) ;• Sin phishing, es decir, como mecanismo anti-phishing ;• Autenticación de Múltiples Factores ;• Prevención de Bots ;• Evitar Múltiples Cuentas (es decir, que se abran por la misma entidad) ;• Para implementar mecanismos de votación de “Un usuario un Voto”, por ejemplo, para: ;oParticipaciones en concursos ;oVotación ;oSondeo ;oCabildeo ;oPeticiones ;• inicio de sesión anónimo pero verificado ;• para crear una lista negra de perfiles, por ejemplo, para proporcionar Medidas contra la Reventa ;• autenticación sin nombres de usuario contraseñas ;• llenado/registro de formularios ;• Restringir el acceso al contenido mediante: ;oUbicación ;oEdad ;oNacionalidad ;oNombre ;oDOB ;oDirección ;oOtros detalles del 'perfil' ;• Enviar la identidad de un usuario a través de Internet ;Las siguientes son configuraciones y/o usos adicionales y útiles del sistema de uPass: ;F2F (Amigo a Amigo/Pares entre Pares) ;El sistema de uPass se puede configurar en un contexto F2F. Por ejemplo, se puede configurar para proporcionar mecanismos para lo siguiente: ;• Entrada a un edificio a través de código QR/NFC ;• entrada a recintos al proporcionar perfil permisos. Los detalles del perfil que se pueden proporcionar incluyen:oCompañía ;oEdad ;oNacionalidad ;oNombre ;oDOB ;oDirección ;o¿Tienes el boleto correcto? ;o¿Tiene la autorización de seguridad correcta? ;ootros detalles del perfil ;• Proporcionar la edad para el control de acceso/punto de venta, por ejemplo, en: ;Discotecas ;Casinos ;Pubs ;Registrarse en una ubicación, por ejemplo, en los siguientes contextos: ;Lista de asistencia, por ejemplo, en escuelas ;Libro de Visitas ;Cursos ;Salud y Seguridad ;Hoteles/BnBs ;Gimnasios ;Registro de las horas trabajadas ;Caso de uso del hotel -reserve a través de conectar, asignar pase al dispositivo, evitar el check-in tarjetas de clave ;Proporcionar el ID a otra persona, por ejemplo, en el contexto de: ;Clasificados ;Citas ;Taxis ;Piso compartido ;Coche compartido ;Empresa que proporcionen el ID de una persona - por ejemplo: ;para uso durante visitas domiciliarias: ;para mostrar al empleador ;para mostrar las calificaciones apropiadas ;Individuo que proporciona el ID a la empresa, por ejemplo: ;Casas de empeño ;Alquiler de coches ;Compras de alto valor ;Bienes con Restricción de Edad ;Recogida de Bienes ;Transporte ;Suministro a Domicilio, por ejemplo, para proporcionar: ;Prueba de Recepción de Bienes ;Autorización a particulares para recoger bienes en su nombre ;F2F y KYC en línea, por ejemplo, en el contexto de: ;Agentes Inmobiliarios/Alquileres ;Creación de cuentas bancarias ;Seguro ;oHipoteca ;oPréstamos Entre Pares ;• El empleado proporciona su ID a la empresa, por ejemplo, para demostrar: ;oDerecho al trabajo inc.: ;■ Visas ;■ Calificaciones ;■ Nacionalidad, etc. ;oAcceso de Usuario a las Aplicaciones Empresariales ;oAcceso al Edificio ;oCertificaciones, por ejemplo: ;■ Curso de Seguridad y Salud ;■ Conductor de Montacargas ;■ Primeros Auxilios ;■ Protección a la Infancia ;■ CRB ;■ Licencia para Ejercer ;oSeguros, por ejemplo: ;■ Seguro de Indemnización ;■ Seguro de responsabilidad civil ;Yotis emitidos por terceros ;Ejemplos de terceros que pueden emitir Yoti de manera útil son: ;• Padres ;• Empresas ;• Organizaciones benéficas, por ejemplo: ;oAyuda en caso de desastres - la organización benéfica puede emitir una identidad temporal hasta el momento en que la infraestructura del país haya mejorado ;oUtilizar Yoti para asignar un identificador único, por ejemplo, un código QR o un chip NFC a una identidad. Yoti es capaz de trabajar sin conexión ;Etiquetas de Activos ;• Asignar una identidad a un objeto ;• Marcas de agua digitales ;oAsignar una identidad a un contenido digital ;oAsignar una identidad a los boletos ;• Etiquetado de mascotas ;• Asignar una identidad a ;oCertificados ;oDocumentos ;IOT (Internet de las Cosas) ;• Asignar permisos a dispositivos conectados a loT en base a una identidad de Yoti ;• Permitir que los dispositivos se comuniquen con las personas ;MOOCS ;• Pruebas en línea, por ejemplo ;oComprobaciones faciales aleatorias para verificar identidad ;oVerificar la identidad del examinado ;oAsignar calificaciones ;Libro de direcciones global ;• Compartir la información de contacto de un usuario con otros que se actualiza cuando el usuario actualiza • Poder restringir el acceso a su información de contacto ;• Compartir tarjetas de visita ;Restricción de contenido en línea ;• Muro de pago frente al contenido ;• Micropagos ;• Servicios de Suscripción ;Microdonaciones ;Sistema de mensajería para que los pacientes de atención médica den y reciban comentarios ;Gestión de programas de fidelización ;registrarse en programas de fidelización ;prueba de membresía, nivel de fidelidad, asignación de puntos ;Gestión del club ;registro a clubes/sociedades ;prueba de membresía, prueba de pago de suscripción, prueba de nivel de membresía ;comunicación con la membresía ;pago de suscripciones y otros ítems relacionados con el club ;Firmas digitales ;firmar contratos en formato electrónico (como DocuSign) ;reconocer el acuerdo con un convenio creado y alojado en Yoti ;Servicios de Escrow ;transferencias de nombres de dominio ;otras transferencias electrónicas de artículos ;transferencias de bienes físicos (por ejemplo, intercambios de ciudades) ;Facturas ;• Un servicio para emitir facturas. Este sería un producto útil para algunos individuos premium de Yoti/proveedores de servicios más pequeños (señora de la limpieza, electricista, plomero, etc.). ;• Interrupción del seguro al utilizar Yoti connect y al verificar la identificación que es posible para mitigar el seguro falso; esto, a su vez, crea una prima más baja debido a un menor riesgo debido a una identidad verificada AML (Lucha Contra el Blanqueo de Capitales) ;• Aplicaciones de Gestión de Credenciales - en Todos los Dispositivos ;• Sistema de Mensajería Privada - Como Wickr pero con una identidad garantizada ;• Cifrado de correos electrónicos utilizando Yoti, por ejemplo, para proporcionar: ;oFirmas digitales y encriptación utilizando las identificaciones de Yoti para obtener permiso ;Bóveda digital ;• Bóveda personal vinculada a la identidad, por ejemplo, para: ;oDocumentos ;oCalificaciones ;oContenido Digital ;oRegistros médicos ;oTestamentos ;oCertificados de acciones ;• Almacenamiento de claves criptográficas - permite a yoti almacenar claves para descifrar documentos seguros almacenados en otros lugares. ;Gestión de boletos ;Verificar identidad ;Impedir Bots ;Impedir Múltiples Cuentas ;Control de Compra de Boletos ;Listas negras ;Perfiles de Revendedores ;Asignar Identidad a los Boletos ;Compra de Boletos (a través de billetera electrónica) ;Reventa Controlada de boletos ;Control de Entrada a Eventos ;Boletas ;Ofrecer a los eventos una participación en los beneficios de la reventa de boletos ;Billetera electrónica ;Construir una billetera electrónica sobre un sistema de identidad ;Ahorros Sociales ;Dinero de bolsillo/Billetera electrónica para niños ;Préstamos de día de pago P2P ;Donaciones benéficas ;Asociar perfiles con pagos sin contacto ;Criptomonedas ;Vincular la identidad con las criptomonedas ;Libro Mayor Seguro, por ejemplo, para gestionar: ;Criptomoneda -elimina la necesidad de libros de contabilidad distribuidos Microdonaciones ;Transferencia de fondos ;Sectores ;Se prevén los siguientes usos dentro de los siguientes sectores: ;Trabajadores independientes ;• Verificar trabajos anteriores, por ejemplo, asociar la identidad a diseños anteriores • Comentarios ;• Evitar múltiples cuentas ;• Pagos (a través de billetera electrónica) ;• Verificar las cualificaciones ;Economía colaborativa ;oB2B (Negocio a Negocio) ;■ Verificar Usuarios ;■ Verificar la propiedad de los bienes compartidos ;■ Registro/Inicio de sesión ;■ Pagos (a través de billetera electrónica) ;oB2C (De empresa a consumidor) ;■ Permitir que los usuarios se envíen identidades entre sí a través de Internet ■ Permitir que los usuarios muestren su identidad en persona ;Clasificados ;oB2B ;■ Verificar Usuarios ;■ Verificar la propiedad de los bienes compartidos ;■ Registro/Inicio de sesión ;oB2C ;■ Permitir que los usuarios se envíen identidades entre sí a través de Internet ■ Permitir que los usuarios muestren su identidad en persona ;■ Pagos (a través de billetera electrónica) ;Citas en línea ;oB2B ;■ Verificar Usuarios ;■ Evitar Bots ;■ Evitar Múltiples Cuentas ;■ Registro/Inicio de sesión ;oB2C ;■ Permitir que los usuarios se envíen identidades entre sí a través de Internet ■ Permitir que los usuarios muestren su identidad en persona ;■ Chat temporal ;Juegos en línea ;AML KYC ;Evitar Bots ;Evitar Múltiples Cuentas ;Inicio de sesión seguro ;Pagos (a través de billetera electrónica) ;Gestión de contenido DRM ;Asignar identidades a Bienes Digitales ;Permitir la reventa de productos digitales a través de Yoti ;Contenido restringido por edad ;Verificación de Edad Anónima ;Inicio de Sesión Seguro ;Evitar que se Compartan los Datos de Inicio de Sesión ;Salas de Chat con Restricción de Edad ;Juegos Infantiles ;Gestión de boletos/Eventos/Conferencias ;Verificar Identidad ;Evitar Bots ;Evitar Múltiples Cuentas ;Controlar la Compra de Boletos ;Listas negras ;Perfiles de Revendedores ;Asignar Identidad a los boletos ;Compra de Boletos (a través de billetera electrónica) ;Reventa Controlada de Boletos ;Control de Entrada a Eventos ;Boletas ;Tercer Sector ;Ayuda en caso de desastre - la organización benéfica puede emitir una identidad temporal hasta el momento en que la infraestructura del país haya mejorado. ;Utilizar Yoti para asignar un identificador único, por ejemplo, un código QR o un chip NFC a una identidad. MOOCs/Formación ;Verificar la Identidad de los Candidatos ;Asignar Calificaciones ;Comprobar la Identidad de los Examinados ;Coincidencia de Caras durante los Exámenes en línea ;Inicio de Sesión Seguro ;Sitios de revisión ;Evitar Bots ;Evitar Cuentas Duplicadas ;Evitar Reseñas Falsas ;Inicio de Sesión Seguro ;Verificar las empresas ;Salud pública ;Verificar empleados ;Verificar visitantes ;Almacenamiento de los Registros de Salud de IPatients ;Gestión de activos ;Entrada al Edificio ;Mensajería Médico a Paciente ;Comentarios de los Pacientes ;Reserva de Citas En Línea ;Servicios de entrega ;Verificar la Identidad de las personas que Recogen paquetes ;Dar permiso a amigos/familiares para que recojan paquetes en su nombre ;Firma de paquetes - Recepción de Entrega ;Verificar los empleados ;Gestión de activos, por ejemplo: ;Los empleados firman la salida de furgonetas/coches ;Reclutamiento ;• Verificar las Identidades de los candidatos, por ejemplo: ;oCalificaciones ;oVisas ;oNacionalidades ;Compartir la identidad con RRHH ;Compartir datos de contacto ;Minoristas ;Descuentos Basados en ítems de perfil ;Programas de Fidelización ;Prueba de membresía ;Prueba de edad ;Competiciones ;Captura de datos de compradores ;EPOS ;Acceso al Edificio ;Inicio de Sesión en Tienda en Línea ;Registro de Tienda en Línea ;Pagos (a través de billetera electrónica) ;Perfiles de la empresa ;Prueba de identidad comercial para el cliente en visitas domiciliarias ;Prueba de cualificaciones al cliente ;Prueba de recepción de la visita ;Constancia de trabajo realizado ;Residencial ;KYC ;Prueba del derecho a vivir ;Compartir contactos ;Servicios financieros ;KYC AML ;Inicio de sesión seguro en línea ;Interrupción del seguro al utilizar Yoti connect y al verificar el ID, podemos mitigar el seguro falso, crea una prima más baja debido a un menor riesgo debido a una identidad verificada ;Acceso al Edificio ;Universidades ;Acceso al Edificio ;Inicio de sesión seguro en línea ;Recepción de Presentaciones de trabajos ;Verificar la identidad de los estudiantes ;Verificar Visas ;• Pagos (a través de billetera electrónica) ;• Préstamo de libros de la biblioteca ;• Membresías de Clubes/Sociedades ;• Verificación de Edad en Bares ;• Lista de asistencia para clases/conferencias ;Viajes ;• Almacenar Boletos ;• Prueba de edad para descuentos ;Sector Público ;• Votación y Sondeos - En línea y Sin Conexión ;Gestión de Activos. ;uPass Connect ;El mecanismo uPass Connect se puede utilizar para los siguientes fines: ;Verificar identidad (ID) En Línea ;Verificar la edad en línea ;Mecanismos de KYC (Conozca a Su Cliente) ;Sin phishing, es decir, como mecanismo anti-phishing ;Autenticación de Múltiples Factores ;Prevención de Bots ;Evitar Múltiples Cuentas (es decir, que se abran por la misma entidad) ;Para implementar mecanismos de votación de “Un usuario un Voto”, por ejemplo, para: ;oParticipaciones en concurso ;oVotación ;oVotación ;oCabildeo ;oPeticiones ;inicio de sesión anónimo pero verificado ;para crear una lista negra de perfiles, por ejemplo, para proporcionar Medidas contra la Reventa autenticación sin nombres de usuario contraseñas ;llenado/registro de formularios ;Enviar la identidad de un usuario a través de Internet ;restringir el acceso al contenido por: ;oUbicación ;oEdad ;oNacionalidad ;oNombre ;oDOB ;oDirección ;oOtros detalles del “perfil” ;• Permitir que los muros de pago funcionen de manera más efectiva al asociar a los usuarios con el contenido deseado probable, ya sea a través del interés expresado o los atributos. ;• Servicios de Suscripción ;Transmisión de contenido para el acceso de un usuario específico, por ejemplo, el usuario “A”, que es un pagador de licencia BBC, puede acceder al contenido por el que ha pagado desde Francia o cualquier otro país. Netflix y otras compañías están luchando con los derechos de acceso de los usuarios móviles sin utilizar la geolocalización como filtro. ;F2F P2P (De amigo a amigo/De igual a igual) ;El sistema de uPass se puede configurar en un contexto F2F. Esto puede funcionar tanto cara a cara a través de un escaneo de código QR/NFC como de forma remota al enviar un enlace a través de una plataforma de mensajería. Por ejemplo, se puede configurar para proporcionar mecanismos para lo siguiente: ;• Entrada a un edificio a través de código QR/NFC ;• entrada a los recintos al proporcionar perfil permisos. Los detalles del perfil que se pueden proporcionar incluyen: ;oCompañía ;oEdad ;oNacionalidad ;oNombre ;oDOB ;oDirección ;o¿Tienes el boleto correcto? ;o¿Tiene la autorización de seguridad correcta? ;oOtros detalles del perfil ;• Proporcionar la edad para el control de acceso/punto de venta, por ejemplo, en: ;oDiscotecas ;oCasinos ;oPubs ;• Pagar simultáneamente por un ítem mientras se proporciona un aspecto de identidad utilizando la billetera electrónica Yoti, por ejemplo, mayor de 18 años ;• Registrarse en una ubicación, por ejemplo, en los siguientes contextos: ;oLista de asistencia, por ejemplo, en escuelas ;oLibro de Visitas ;oCursos ;oSalud y Seguridad ;oHoteles/BnBs ;oGimnasios ;oHospitales/ Médicos Cirugía ;oOficinas ;oCentros Comerciales ;oAeropuertos ;• Registro de las horas trabajadas ;• Caso de uso del hotel - reservar a través de conectar, asignar el pase al dispositivo, evitar el check-in tarjetas de acceso ;• Proporcionar el ID a otra persona, por ejemplo, en el contexto de: ;oClasificados ;oCitas ;oTaxis ;oPiso compartido ;oCoche compartido ;• Empresa que proporcione el ID de una persona - por ejemplo: ;oPara uso durante las visitas domiciliarias: ;opara mostrar al empleador ;opara mostrar las calificaciones apropiadas ;• El individuo proporciona el ID a la empresa, por ejemplo: ;oPrestamistas ;oAlquiler de coches ;oCompras de Alto Valor ;oBienes con Restricción de Edad ;oRecogida de mercancías ;oTransporte ;Demostrar que tienes la edad requerida en el momento de la compra al comprar alcohol, cigarrillo o cualquier producto con restricción de edad. El comprador no solo compra convenientemente los bienes que necesita, sino que el vendedor también recibirá un recibo inmutable que demuestra que se verificó la edad y quién realizó la compra. ;• Entrega a Domicilio, por ejemplo, para proporcionar: ;oPrueba de Recibo de Mercancías ;oAutorización a individuos para recoger bienes en su nombre ;oAcceso seguro a una unidad de almacenamiento a través de connect ;• F2F y KYC en línea, por ejemplo, en el contexto de: ;oAgentes Inmobiliarios/Alquileres ;oCreación de cuentas bancarias ;oSeguro ;oHipoteca ;oPréstamos Entre pares ;• El empleado proporciona su ID a la empresa, por ejemplo, para demostrar: ;oDerecho al trabajo inc.: ;■ Visas ;■ Calificaciones ;■ Nacionalidad, etc. ;oAcceso de los usuarios a las Aplicaciones Empresariales ;oAcceso al Edificio ;oCertificaciones, por ejemplo: ;Curso de Seguridad y Salud ;Conductor de Montacargas ;Primeros Auxilios ;Protección a la Infancia ;CRB/DBS ;Licencia para Ejercer ;Seguros, por ejemplo: ;Seguro de Indemnización ;• Seguro de responsabilidad civil ;Yotis emitidos por terceros ;Ejemplos de terceros que pueden emitir Yoti de manera útil son: ;• Padres ;• Empresas ;• Organizaciones benéficas, por ejemplo: ;oAyuda en caso de desastre - la organización benéfica puede emitir una identidad temporal hasta el momento en que la infraestructura del país haya mejorado. ;oUtilizar Yoti para asignar un identificador único, por ejemplo, un código QR o un chip NFC a una identidad. Yoti es capaz de trabajar sin conexión ;• Portal de Yoti que permite a los comerciantes, proveedores, empresas, etc. configurar un perfil de empresa de Yoti. Desde allí pueden asignar atributos y a su personal, clientes, etc. que les otorgarán derechos o autenticación. Esto se podría manifestar en el hombre del gas y el pase de temporada. ;Libreta de direcciones global ;• Yoti permitirá que un perfil de atributos no solo se comparta con varias personas, sino que también se revoque cuando lo desee. ;• Como tal, los usuarios no necesitarán en última instancia mantener sus propios directorios de contactos, sino que existirá una libreta de direcciones global con atributos dinámicos actualizados con un nexo de permisos que existen entre los usuarios. ;• Compartir la información de contacto de un usuario con otras personas que se actualiza cuando el usuario actualiza ;• Poder restringir el acceso a su información de contacto ;• Compartir tarjetas de visita ;VRM (Gestión de relaciones con proveedores) ;Yoti es una tecnología facilitadora que podría hacer realidad las visiones de Doc Searls y otros. En esencia, a través de una bóveda digital y de identidad certificada, segura y fiable (ver a continuación) se podría: ;• Divulgación pública de datos personales expresados en un deseo de comprar algo, lo que estaría dispuesto a pagar por ello y algunos términos bajo los cuales estaría dispuesto a comerciar. ;• Los proveedores pueden responder a esos términos con ofertas. ;Es necesario establecer un protocolo que defina la forma en que se transmiten, se consumen y se responden estos términos. ;Es necesario establecer un foro en el que se puedan buscar y aprovechar las oportunidades. ;Es necesario desarrollar aplicaciones que ofrezcan lo anterior. ;Bóveda digital ;• Aplicaciones que utilizan una identidad fiable como un mecanismo para acceder y controlar un almacén de datos personales. ;• Aplicaciones en las que los atributos se pueden mantener y cifrar de forma segura. ;• Bóveda personal vinculada a la identidad, por ejemplo, para: ;oDocumentos ;oCalificaciones ;oContenido Digital ;oRegistros médicos ;oTestamentos ;oCertificados de Acciones ;• Almacenamiento de claves criptográficas - permite a yoti almacenar claves para descifrar documentos seguros almacenados en otros lugares. ;Contenido y productos con restricción de edad ;• Verificación de Edad Anónima ;• Inicio de Sesión Seguro ;• Evitar que se Compartan los Detalles de Inicio de Sesión ;• Salas de Chat con Restricción de Edad ;• Juegos Infantiles ;Aplicaciones ;Seguimiento de Activos ;Ya sea a través de etiquetas a objetos físicos o a través de dispositivos y nodos virtuales podemos asociar identidades a los activos. ;• Aplicaciones que ayudan a la asociación de identidades y políticas a los recursos. ;• Aplicaciones que controlan un registro de activos con sus identidades y políticas ;• Asignar una identidad a un objeto ;• Asignar atributos útiles de Yoti a etiquetas RFID, códigos QR y otros identificadores únicos que, cuando se consumen, proporcionan datos útiles. Por ejemplo, se puede escanear una billetera perdida con una etiqueta RFID con atributos personales y se pueden suministrar datos con los que el buscador puede contactar y devolver el ítem. ;• Marcas de agua digitales ;oAsignar una identidad a un contenido digital ;oAsignar una identidad a los boletos ;• Etiquetado de mascotas ;• Asignar una identidad a ;oCertificados ;oDocumentos ;oCertificados de acciones ;IOT (Internet de las Cosas) ;Asignar permisos a dispositivos conectados a IoT en base a una identidad de Yoti ;Permitir que los dispositivos se comuniquen con las personas ;Pago a sistemas a través de la billetera electrónica (por ejemplo, accediendo a un vehículo autónomo) Proporcionar una capa de seguridad a los dispositivos. Cualquier dispositivo IOT puede garantizar que los usuarios autorizados puedan acceder a él y controlarlo. Tanto el dispositivo como el usuario han recibido una identidad a través de Yoti y, como tal, se pueden controlar los permisos. ;Aplicaciones que suministran la funcionalidad anterior ;Microdonaciones ;Provisión de pagos a través de una aplicación en la que se han cumplido las regulaciones y el cargo por transacción fue insignificante y, por lo tanto, valió la pena. ;Sistema de mensajería para que los pacientes y el personal de atención médica den y reciban comentarios Comunicar la experiencia de forma anónima o directa ;Construir una base de datos de resultados y aprendizajes para la mejora continua ;Gestión de programas de fidelización ;registrarse en programas de fidelización ;prueba de membresía, nivel de fidelidad, asignación de puntos ;Gestión del club ;registro a clubes/sociedades ;prueba de edad ;prueba de membresía, prueba de pago de suscripción, prueba de nivel de membresía ;Comunicación con la membresía ;Pago de suscripciones y otros ítems relacionados con el club ;Firmas digitales ;firmar contratos en formato electrónico (como DocuSign) ;reconocer el acuerdo con un convenio creado y alojado en Yoti ;Servicios de Escrow ;transferencias de nombres de dominio ;otras transferencias electrónicas de ítems ;transferencias de bienes físicos (por ejemplo, intercambios de ciudades) ;Facturas ;• Un servicio para emitir facturas. Este sería un producto útil para algunos individuos premium de Yoti/proveedores de servicios más pequeños (señora de la limpieza, electricista, plomero, etc.). ;AML (Lucha Contra el Blanqueo de Capitales) ;• Asociar la identidad a las transacciones financieras. ;• Asociar la identidad a las cadenas de bloques ;• Proporcionar recibos inmutables y auditables a las transacciones realizadas fuera de las plataformas bancarias tradicionales (1850 - 2010), es decir, transacciones a través de mensajes de texto, correo electrónico, aplicaciones de pago móvil, etc. ;• Aplicaciones de Gestión de Credenciales - en todos los Dispositivos ;• Sistema de Mensajería Privada - Como Wickr pero con una identidad garantizada ;• Cifrado de correos electrónicos utilizando Yoti, por ejemplo, para proporcionar: ;oFirmas digitales y cifrado con identidades Yoti para obtener permiso ;Gestión de boletos y medidas contra la reventa ;Verificar Identidad ;Evitar Bots ;Evitar Múltiples Cuentas ;Controlar la Compra de Boletos, boletas, restricciones de edad, solo base de fanáticos, etc. ;Listas negras ;Listas VIP, promociones para miembros seleccionados ;Perfiles de Revendedores, monitorización del comportamiento de revendedor y restricción del acceso futuro Asignar Identidad a Boletos ;Compra de Boletos (a través de billetera electrónica) ;Reventa Controlada de boletos ;Control de Entrada a Eventos ;Boletas ;Ofrecer a los eventos una participación en los beneficios de la reventa de entradas ;Suministrar boletos a través de una cadena de bloques ;Tu cara es tu boleto - no se requiere boleto de papel ni código QR. ;Aplicaciones que suministran la funcionalidad anterior ;Billetera electrónica ;Construir una billetera electrónica sobre un sistema de identidad ;Ahorros Sociales ;Dinero de bolsillo/Billetera electrónica para niños, control parental y supervisión con un mecanismo simple para agregar fondos. ;Préstamos de día de pago P2P ;Donaciones Benéficas ;Asociar perfiles con pagos sin contacto ;Criptomonedas ;Vincular la identidad con las criptomonedas ;Libro Mayor Seguro, por ejemplo, para gestionar: ;Criptomonedas - elimina la necesidad de libros de contabilidad distribuidos ;Microdonaciones ;Transferencia de fondos ;Transferencia de datos de identidad junto con el pago, por ejemplo, edad de transferencia, género junto con el pago a un proveedor ;Aplicaciones de Arrendamientos ;Visión general ;Proporcionar una alternativa digital y ágil para que inquilinos, propietarios y agentes de alquiler verifiquen identidades, empleos, residencias e historiales crediticios, con referencia para garantizar el cumplimiento de toda la legislación vigente. ;Conozca a Su Cliente - Valide la identidad de los inquilinos, para confirmar, nombre completo, nacionalidad, fecha de nacimiento, dirección actual (3 años de historial), validación de cuenta bancaria. Incluir cheques de derecho a alquiler (pasaporte o documento de identidad del EEE, tarjeta de residencia permanente o documento de viaje que muestre permiso de residencia indefinido, documento de estatus migratorio del Ministerio del Interior, certificado de registro o naturalización como ciudadano británico. ;Verificaciones de crédito - para incluir el Puntaje de Aceptabilidad de la Comprobación de Crédito, búsqueda de historial de crédito durante un período de seis años, Sentencias de Tribunales del Condado (CCJ) y comprobaciones de bancarrota, acuerdos voluntarios individuales y/o información del plan de gestión de deudas, deudas, incumplimientos, atrasos en el pago del alquiler y verificaciones de recuperación. ;Verificación de empleo - Prueba de empleo (al menos 2 años), nombre de la empresa, datos de contacto, fecha de inicio, salario anual (incluidas horas extras y bonificaciones), período de prueba. Cuentas comerciales si trabaja por cuenta propia. ;Datos de empleo anterior, nombre de la empresa, datos de contacto, fecha de inicio, salario anual (incluidas las horas extras y las bonificaciones). ;Arrendador anterior - Referencia de arrendadores actuales o agencias de alquiler - Nombre, detalles de contacto de los agentes/arrendadores y dirección y fechas de todos los lugares en los que ha vivido en los últimos 3 años Alquiler de garantes - para estudiantes o jóvenes que alquilan por primera vez, o no puede proporcionar que puede pagar el alquiler. El garante tendrá que firmar un documento en el que se compromete a pagar el alquiler si usted no lo hace. ;Por lo general, el garante tendría que ser residente del Reino Unido y poseer una propiedad ;Página del sitio web y requisitos ;URL del sitio web ;Inicio de Sesión de Yoti ;Arrendatario ;Nombre completo ;• Nacionalidad*

• DoB

• Dirección Actual

• Si no es Reino Unido, EEC Suiza

Visa del Reino Unido (permiso de residencia, etc.)

Chip

Características de Seguridad (donde el chip no está presente)

Verificación de Crédito (hasta 6 años de historia)

Puntaje de crédito

Asequibilidad para inquilinos

Dirección vinculada

CCJ

Censo Electoral

Insolvencia

El usuario tiene que dar su consentimiento para que se lleve a cabo el informe de crédito Empleador actual:

Nombre de la Empresa:

Dirección de la Empresa:

Contacto: Nombre Apellido

Dirección de Correo Electrónico: (x2)

Número de Teléfono:

Fecha de Inicio del Empleado: Día (opcional) Mes y año (obligatorio)

Fecha de Finalización del empleado: Día (opcional) Mes y año (obligatorio) Cargo del Trabajo:

Salario Anual:

Período de Prueba (marque la casilla):

Empleador anterior (si el empleo actual tiene menos de 2 años)

Nombre de la Empresa:

Dirección de la Empresa:

Contacto: Nombre Apellido

Dirección de Correo Electrónico: (x2)

Número de Teléfono:

Fecha de Inicio del Empleado: Día (opcional) Mes y año (obligatorio)

Fecha de Finalización del Empleado: Día (opcional) Mes y año (obligatorio) Salario Anual:

Referencia del empleador

Recibir correo electrónico con enlace

• Iniciar sesión - Nombre de usuario y Contraseña (obtener Yoti, ¿iniciar sesión con Yoti?) • Confirma los detalles de los inquilinos:

oFecha de Inicio del Empleado: Día (opcional) Mes y año (obligatorio)

oFecha de Finalización del Empleado: Día (opcional) Mes y año (obligatorio)

oCargo del Trabajo:

oSalario Anual:

Marque la casilla para confirmar - al completar esta referencia, acepta que está autorizado a proporcionar esta información. Es un delito proporcionar una referencia fraudulenta. Esta referencia se utilizará como parte de nuestra evaluación de la solicitud de las personas mencionadas anteriormente. De acuerdo con la Ley de Protección de Datos de 1998, si lo solicita, se puede proporcionar una copia de su referencia a las personas mencionadas anteriormente y/o al cliente en nombre del cual actuamos. Declaro que las declaraciones anteriores son verdaderas y completas a mi leal saber y entender, y que no se ha ocultado, suprimido u omitido ningún hecho material.

Referencia anterior del propietario/agencia (últimos 3 años)

Nombre del Propietario/Agencia:

Persona de Contacto: Nombre Apellido

Dirección de Correo Electrónico:

Número de Teléfono:

Dirección anterior:

Fecha de Inicio del Alquiler: Día (opcional) Mes y año (obligatorio)

Fecha de Finalización del Alquiler: Día (opcional) Mes y año (obligatorio)

Comentarios:

oAtrasos

oDaño

oAOB

Garante

Nombre Completo

Nacionalidad (debe ser residente en el Reino Unido)

DoB

Dirección Actual

Nombre del Empleado:

Dirección de la Empresa:

Contacto: Nombre Apellido

Dirección de Correo Electrónico: (x2)

Número de Teléfono:

Fecha de Inicio del Empleado: Día (opcional) Mes y año (obligatorio)

Fecha de Finalización del Empleado: Día (opcional) Mes y año (obligatorio)

Cargo del Trabajo:

Salario Anual

Cuando un inquilino solicitante selecciona el tiempo en el empleador actual como menos de 3 meses, el sitio debe solicitar que el inquilino complete una sección de detalles del Garante. El informe de crédito, etc., se debe obtener para el Garante en lugar del inquilino solicitante. También se requiere un Garante cuando el salario es demasiado bajo o se obtiene una mala calificación crediticia/criterio (el Agente de arrendamientos debe poder seleccionar sus propios umbrales para automatizar el sistema y exigir al garante por adelantado para reducir el intercambio de opiniones.

Cuando se requiera un garante, podemos ofrecer el acuerdo de escritura de garantía como parte del paquete. Actualmente, esto lo hace el agente de alquiler en lugar de la empresa de referencia del inquilino.

Solicitudes de Recepción

¿Qué es Yoti Reception?

Yoti Reception es una alternativa digital a un libro de visitas encuadernado en papel. Es mucho más adaptable que una solución no digital que permite a los edificios de oficinas notificar a los habitantes cuando tienen un visitante, al tiempo que mejora la seguridad mediante el ID digital de los visitantes.

¿Qué problema está tratando de resolver Yoti Reception?

Yoti Reception es una solución a múltiples problemas que se han detallado a continuación:

¿Cómo se suelen abordar los problemas en la actualidad?

La solución actual implementada por la mayoría de los edificios es exigir a los visitantes que firmen su nombre y datos en un libro de registro encuadernado en papel que se encuentra en la recepción.

¿Por qué será una mejora de Yoti Reception?

• Notificará a la persona apropiada que hay un visitante esperándolo, reduciendo el tiempo en el que los visitantes tienen que pasar desatendidos en el vestíbulo de un edificio

• Puede registrar detalles en un formato digital que es fácilmente accesible y rastreable tanto a nivel de empresa como a nivel de edificio

• Se integrará con la funcionalidad de ID de Yoti, lo que brindará a los edificios y empresas la tranquilidad de que las personas que ingresan a su edificio 1) no pueden mentir sobre su identidad y 2 ) son responsables al registrar sus identidades reales

¿Habrá algún requisito para que un visitante presente un ID, y si no, por qué no?

No, esto se debe a que el servicio es principalmente una solución de optimización que mejora la experiencia del visitante en lugar de una mejora de la seguridad. Exigir a los visitantes que presenten su ID aumenta la fricción dentro de la transacción. En el futuro, los edificios podrían deshabilitar el inicio de sesión de correo electrónico Aplicaciones para discotecas

Un sistema de identidad que se utiliza en lugares donde las empresas están legalmente obligadas a verificar la identidad/edad de las personas en la vida real.

La gente está acostumbrada a presentar su identidad antes de entrar a un recinto que sirve alcohol, lo que significa que van a esperar utilizar su Yoti en el presente documento, ya sea que ofrezcamos este producto o no. Este documento se establece la estrategia general para este sector.

Yoti es un sistema de identidad que se puede utilizar en línea y sin conexión.

1.1 El problema que estamos resolviendo

Libre de impuestos y reembolsos fiscales

Utilizar la tecnología para simplificar los esquemas de reembolso de impuestos internacionales, que son complejos de entender, y requieren mucho tiempo para operar. Además, hay una gran cantidad de errores por parte de los solicitantes y de las autoridades fiscales que son costosos de rectificar. La combinación de la identidad de Yoti en un teléfono, junto con los atributos de la visa que permite al ciudadano extranjero ser elegible para compras libres de impuestos en el país y con el uso de la billetera electrónica que realiza estos pagos, nuestra aplicación:

Para particulares

ID individual

A partir del pasaporte clasifique su nacionalidad

A partir de la VISA clasifíquelos en categoría 1,2 o 3

Presénteles una explicación de los beneficios de lo que pueden beneficiarse y las tiendas de las que pueden obtener este beneficio.

Hacerles confirmar los términos y condiciones de la devolución tanto para HMRC como para aceptar y cobrar que la tienda desee aplicar a este proceso

Realice un pago desde YotiWallet o una alternativa para el pago completo, que incluye el IVA.

Agregue los artículos comprados a una cesta de artículos elegibles comprados y visualice un posible valor de reembolso que se reclamará una vez que se confirme con éxito en la aduana.

Para el personal fronterizo de HMRC o el personal autorizado de MiPass

ID del individuo que está frente a ellos

Registre la fecha en que salen de la EU (Billete/Tarjeta de embarque, etc.)

Proporcione una lista de verificación de todos los artículos que se reclaman para que el personal pueda optar por comprobar/verificar.

Certificar que la exportación es correcta

Para el comerciante

Yoti comprueba que la persona sea quien dice ser y confirme que califica para el esquema.

Exigir la aceptación del esquema y los cargos administrativos de la tienda y firmar el acuerdo de ambas partes Acepta un pago de YotiWallet o una alternativa por el valor total que incluye el IVA.

• El panel de control del comerciante debe visualizar las compras totales de todos los artículos calificados que están esperando confirmación en la aduana y aquellos que ya han sido aprobados, y los reembolsos que se deben pagar a la cuenta de MiWallet de las personas.

Para el líder del grupo turístico

Vincula a todas las personas asociadas a su grupo y realiza un seguimiento de sus compras en cada tienda para que puedan beneficiarse de la comisión.

Sectores

MOOCs/Formación

• Pruebas en línea, por ejemplo

oComprobaciones faciales aleatorias para verificar la identidad

oVerificar la identidad del examinado

oComprobar la identidad de los examinadores

oAsignar calificaciones

oInicio de Sesión Seguro

oAplicaciones que suministran la funcionalidad anterior.

Trabajadores independientes

Verificación de trabajos Anteriores, por ejemplo, asociar la identidad a diseños anteriores

Comentarios

Evitar múltiples cuentas

Pagos (a través de billetera electrónica)

Verificar las cualificaciones

Establecer un contrato entre 2 partes antes de venir al sitio. Por ejemplo, un plomero puede especificar un cargo por llamada y un tiempo de £x y materiales como sus términos, y el comprador aceptará estos términos antes de que el plomero parta para el trabajo. De manera similar, el comprador esperará que se lleve a cabo un trabajo de calidad y firmará que el trabajo se ha realizado de acuerdo con los estándares adecuados. Por lo tanto, menos ambigüedad y fiestas felices.

• Aplicaciones que suministran esta funcionalidad.

Economía colaborativa

B2B (de empresa a empresa)

Verificación de Usuarios

Garantía de identidad en un registro inmutable en caso de que ocurra algo nefasto o desafortunado.

Verificar la propiedad de los bienes compartidos

Registro/Inicio de Sesión

Pagos (a través de billetera electrónica)

B2C (De empresa a consumidor)

Permitir que los usuarios se envíen identidades entre sí a través de Internet

Permitir que los usuarios muestren su identidad en persona

Clasificados

• Verificar Usuarios

Verificar de la propiedad de los bienes

Registro/Inicio de Sesión

Permitir que los usuarios muestren su identidad en persona

Pagos (a través de billetera electrónica)

Mayor seguridad al saber con quién está tratando

Reducción del fraude al saber con quién está tratando.

Reseñas en las que se puede ser fiable

Aplicaciones que suministran la funcionalidad anterior.

Citas en línea

Verificar Usuarios

Evite Bots

Evitar Múltiples Cuentas

Registro/Inicio de Sesión

Permitir que los usuarios se envíen su identidad entre sí a través de Internet antes de la reunión. Aumentar la fiabilidad, disminuir el engaño.

Permitir que los usuarios muestren su identidad en persona

Proporcionar un registro inmutable de intercambio de identidad.

Chat Temporal

Por ejemplo

Una persona se puede registrar en el sitio utilizando información verificada. Esto evitaría que los usuarios creen perfiles completamente falsos, creen múltiples perfiles o mientan sobre detalles tal como la edad.

Antes de ir a una cita, las dos personas podrán enviarse su identidad mediante un enlace a través de sms/correo electrónico u otra función de chat para que ambos sepan con quién se van a reunir. Luego, cuando se reúnan en persona, podrán hacer otra interacción utilizando el sistema, dándoles a ambos un recibo con marca de tiempo de la reunión, de tal manera que si algo sucede, ambas partes podrían confirmar exactamente con quién se reunieron y cuándo.

Juegos en Línea

AML KYC

Evitar Bots

Eliminar a los robots que manipulan los juegos y engañan a los jugadores humanos

Evitar Múltiples Cuentas

Inicio de Sesión Seguro

Pagos (a través de billetera electrónica)

Gestión de contenido DRM

Asignar Identidades a Bienes Digitales

Permitir la reventa de bienes digitales a través de Yoti

Gestión de boletos/Eventos/Conferencias

Verificar Identidad

Evitar Bots

Evitar Múltiples Cuentas

Controlar la Compra de Boletos

Listas negras

Perfiles de Revendedores

Asignar Identidad a los Boletos

Compra de Boletos (a través de billetera electrónica)

Reventa Controlada de boletos

Control de Entrada a Eventos

Boletas

Tercer Sector

Ayuda en caso de desastre - la organización benéfica puede emitir una identidad temporal hasta el momento en que haya mejorado la infraestructura del país.

Utilizar Yoti para asignar un identificador único, por ejemplo, un código QR o un chip NFC a una identidad. Sitios de revisión

Evitar Bots

Evitar Cuentas Duplicadas

Evitar Reseñas Falsas

Inicio de Sesión Seguro

Verificar Empresas

Salud Pública

Verificar Empleados

Verificar Visitantes

Almacenamiento de los Registros de Salud de IPatients

Gestión de activos

Entrada al Edificio

Mensajería Médico a Paciente

Comentarios de los Pacientes

Reserva de Citas en Línea

Acceso seguro a los registros de cabecera para los profesionales médicos

Acceso del paciente a los registros médicos

Acceso del paciente a la reserva de citas en línea

Servicios de entrega

• Verificar la Identidad de las Personas que Recogen paquetes

• Dar permiso a amigos/familiares para que recojan paquetes en su nombre

• Firma de paquetes - Recepción de Entrega

• Verificar los empleados

• Gestión de activos, por ejemplo:

oLos empleados firman la salida de furgonetas/coches

Seguro

Interrupción del seguro al utilizar Yoti connect y cara a cara como mecanismo para:

• Verificar ID de manera más oportuna, reduciendo el tiempo requerido para establecer con precisión si un potencial es quien dice ser.

• Una vez verificada la identidad a un nivel muy alto, se puede juzgar mejor el riesgo y posicionar las primas al nivel deseado.

• El fraude de seguros se puede reducir.

• Se pueden desarrollar aplicaciones que alineen rápidamente a las personas con las políticas

• Se pueden desarrollar aplicaciones que permitan a quienes buscan un seguro exponer sus perfiles a los proveedores.

• Emisión de certificados para ser almacenados como un atributo compartible en el sistema Yoti.

Reclutamiento

• Verificar Identidades de los candidatos, por ejemplo:

oCalificaciones

oVisados - comprobación de su derecho a trabajar

oNacionalidades

• Compartir la identidad con RRHH

• Compartir detalles de contacto

Los detalles se pueden compartir en persona - a través de una comprobación cara a cara, o se pueden compartir de forma remota - a través de páginas web específicas de la empresa, que contienen códigos QR que se comunican a los solicitantes por correo electrónico o mediante la integración del sitio web.

Minoristas

Descuentos Basados en ítems de perfil

Programas de fidelización

Prueba de Membresía

Prueba de edad

Competiciones

Captura de Datos de compradores

EPOS

Acceso al Edificio

Inicio de Sesión a Tienda en Línea

Registro de Tienda en Línea

• Pagos (a través de billetera electrónica)

Perfiles de la Empresa

• Prueba de identidad comercial para el cliente en visitas domiciliarias

• Prueba de cualificación al cliente

• Prueba de recepción de la visita

• Constancia de trabajo realizado

Por ejemplo, es posible que British Gas desee emitir una credencial/perfil a uno de sus empleados, quien puede mostrárselo al propietario de la vivienda. El propietario de la vivienda verá la fotografía del operativo de Gas que está emitida y, por lo tanto, certificada por la compañía de gas. Ambas partes recibirán un recibo del intercambio. British Gas puede ver el registro de actividad de los empleados y la ubicación GPS.

Residencial

Prueba del derecho a vivir

Compartir contactos

Los propietarios realizan verificaciones de crédito y KYC asequibles a los posibles inquilinos antes de invertir tiempo para mostrarles el lugar.

Los inquilinos emiten un perfil explicando cuál es su presupuesto y qué buscan para recibir ofertas.

Servicios financieros

KYC

Registro rápido

AML

Inicio de sesión seguro en línea

Interrupción del seguro al utilizar Yoti connect y al verificar ID podemos mitigar el seguro falso, crea una prima más baja debido a un menor riesgo debido a una identidad verificada

Código QR único en el sobre o documento interno, escaneado utilizando Yoti para confirmar (biométricamente) el recibo por el destinatario previsto

Acceso al Edificio

Activar Tarjetas, autorización/verificación remota de tarjetas. Qué códigos impresos en las tarjetas podemos pedirle al usuario que escanee el código para confirmar que es él quien lo está utilizando (por ejemplo, cuando un banco congela su tarjeta cuando está en el extranjero y le pide que le devuelva la llamada para prevenir el fraude). Al escanear un código al recibir la tarjeta, puede activarla.

Retiros de ATM, en el futuro esto se puede identificar sin necesidad de una tarjeta de efectivo.

Incorporación de clientes y conexión de sus datos biométricos a una aplicación bancaria en una sola transacción

Una vez que se ha verificado que una tarjeta ha sido recibida por un usuario de Yoti, podemos registrar un atributo de tarjeta único contra este usuario dentro de su conjunto seguro de atributos de Yoti. Previa solicitud, un usuario puede confirmar que no solo es el usuario que se espera en la transacción, sino también que está en posesión del atributo único de la tarjeta. Esto puede reemplazar los procesos de autenticación de tarjetas tal como 3DSecure, Verified por Visa y cualquier otro esquema similar que brinde a los emisores de tarjetas la confianza de que la tarjeta es utilizada por la persona autorizada. Un caso de uso típico sería cuando se realiza una compra de bienes o servicios en línea utilizando una tarjeta de crédito y se le pide que realice una autenticación adicional.

Descripción general de Yoti para instituciones financieras:

Universidades

Acceso al Edificio

Inicio de sesión seguro en línea

Recepción de Presentaciones de trabajos

Verificar la identidad de los estudiantes

Verificar visas

Pagos (a través de billetera electrónica)

Préstamo de libros de la biblioteca

Membresías de Clubes/Sociedades

Verificación de Edad en Bares

Pase de lista para conferencias/seminarios

Almacenar digitalmente las calificaciones de los Certificados Universitarios

Descuentos y ofertas para estudiantes

Aplicar préstamos estudiantiles

Líneas aéreas

Comprar el billete de avión a través de la billetera electrónica de Yoti y, al mismo tiempo, adjuntar todos los detalles de ID al boleto

Proporcionar la identidad al comprar el boleto de avión y adjuntar este boleto a un Yoti

Conectar la tarjeta de embarque con la identidad

Almacenar la tarjeta de embarque en Yoti

Proporcionar su identidad y prueba de compra simultáneamente en el aeropuerto

Trabajar con las aerolíneas, los aeropuertos y las autoridades fronterizas para acelerar el transporte de pasajeros de manera segura a través de áreas de alta seguridad.

Aplicaciones que suministran la funcionalidad anterior

Viajes

• Almacenar boletos

• Prueba de edad para descuentos

Sector público

• Votación y Sondeo - En Línea y Sin Conexión

• Gestión de Activos

• Creación de registros públicos inmutables que contengan identidad, es decir, el registro de la propiedad, etc. Adulto

El sector de los adultos no está suficientemente regulado y, por lo tanto, las personas menores de la edad requerida para acceder a contenidos para adultos a menudo pueden hacerlo fácilmente cuando obtienen acceso a Internet sin restricciones. Los gobiernos están declarando que instigarán el cambio, pero carecen de herramientas para hacerlo, aparte de insistir en que los ISP bloqueen a los proveedores que no adquieran detalles de Tarjetas de Crédito o documentos de ID como prueba de edad. Yoti permitirá a los usuarios certificar de forma anónima que hay más de la edad requerida, sin dar nombres, DOB, dirección u otros atributos. Al utilizar la API de Yoti, un sitio para adultos puede simplemente como una respuesta de Yoti a una pregunta, por ejemplo: “¿Esta persona tiene más de 18 años”? El servicio de validación de Yoti responderá “Sí” y les entregará un recibo anónimo para confirmar que han alcanzado el estándar gubernamental requerido.

Los casos de uso adicionales se exponen en las tablas 1 y 2 al final de la Descripción Detallada.

Aunque lo anterior se ha descrito en términos de realizaciones específicas, estas no son exhaustivas. El alcance no está limitado por las realizaciones descritas, sino sólo por las siguientes reivindicaciones.

��

Claims

REIVINDICACIONES

1. Un sistema de identidad digital (14) que comprende:

una interfaz de ordenador para recibir mensajes electrónicos; y

uno o más procesadores de hardware (114) configurados para ejecutar:

un módulo de inscripción (14a) configurado para recibir un ítem de datos capturado desde un documento de identidad (10), y crear en el almacenamiento electrónico persistente una identidad digital que comprende el ítem de datos; un módulo de creación de credenciales configurado para transmitir del sistema de identidad digital (14) a un dispositivo de usuario (12) a través de la interfaz de ordenador una credencial (30) para almacenar en el dispositivo de usuario (12), la credencial (30) está unida a la identidad digital; y

un servicio de validación (14b) configurado para recibir un mensaje electrónico que comprende la credencial (30) e identificar un dispositivo objetivo (52), validar la credencial (30) y, si la credencial (30) es válida, utilizar la credencial (30) para transmitir desde el sistema de identidad digital (14) al dispositivo objetivo (52), un mensaje electrónico para que el ítem de datos de la identidad digital esté disponible para el dispositivo objetivo (52).

2. Un sistema de identidad digital (14) de acuerdo con la reivindicación 1, en el que el uno o más procesadores (114) se configuran para ejecutar un módulo de publicación configurado para publicar el ítem de datos de la identidad digital, al almacenar una versión del ítem de datos en una ubicación de memoria (35) del sistema de identidad digital (14) accesible al dispositivo objetivo (52), en el que publicar el ítem de datos de la identidad digital hace que el ítem de datos de la identidad digital esté disponible para el dispositivo objetivo (52), y en el que la versión del ítem de datos publicada en la ubicación de memoria (35) del sistema de identidad digital (14) no se ve afectada por futuras modificaciones de la identidad digital para proporcionar una instantánea del ítem de datos de la identidad digital en el momento de una transacción en la que se recibe el mensaje electrónico.

3. Un sistema de identidad digital de acuerdo con la reivindicación 1, en el que uno o más procesadores (114) se configuran para ejecutar un servicio de verificación (40) configurado para comparar los datos capturados del documento de identidad (10) con un identificador capturado de un usuario en el dispositivo del usuario (12); y en el que la creación de la identidad digital, la emisión de la credencial (30) o la transmisión del mensaje electrónico al dispositivo objetivo (52) está condicionada a que el identificador coincida con los datos capturados del documento de identidad (10).

4. Un sistema de identificación digital de acuerdo con la reivindicación 3, en el que el identificador es un identificador biométrico y los datos son datos biométricos.

5. Un sistema de identidad digital de acuerdo con la reivindicación 1, en el que el sistema de identidad digital se configura para asociar la identidad digital con un activo.

6. Un sistema digital de acuerdo con la reivindicación 5, en el que el activo se asocia con la identidad digital de tal manera que el usuario puede utilizar el activo al presentar la credencial (30) al dispositivo objetivo (52) para transmisión en el mensaje electrónico al servicio de validación (14b) o al transmitir la credencial al servicio de validación (14b) en el mensaje electrónico.

7. Un sistema de identidad digital de acuerdo con la reivindicación 6 , en el que el mensaje electrónico transmitido al dispositivo objetivo (52) hace que el activo o la información relacionada con el activo esté disponible para el dispositivo objetivo (52).

8. Un sistema de identidad digital de acuerdo con la reivindicación 5, en el que el activo es un activo físico, en el que los datos que identifican el activo físico se almacenan en el sistema de identidad digital (14) en asociación con la identidad digital.

9. Un sistema de identidad digital de acuerdo con la reivindicación 1, en el que el dispositivo objetivo (52) se identifica mediante una credencial de entidad objetivo (30v) incluida en el mensaje.

10. Un sistema de identidad digital de acuerdo con la reivindicación 1, en el que el mensaje electrónico se recibe desde el dispositivo objetivo (52), se ha capturado la credencial (30) en el dispositivo objetivo (52).

11. Un método implementado por ordenador para crear una identidad digital que comprende:

en un dispositivo de usuario (12), capturar un ítem desde datos de un documento de identidad;

crear en un procesador (114) del dispositivo del usuario un mensaje electrónico que comprende el ítem de datos; transmitir el mensaje electrónico desde el dispositivo del usuario (12) hasta un sistema de identidad digital (14); recibir en el dispositivo del usuario (12) del sistema de identidad digital (14) un mensaje electrónico que comprende una credencial (30), que está unida a una identidad digital que comprende el ítem de datos, se ha creado la identidad digital en el sistema de identidad digital (14) en respuesta al mensaje electrónico que comprende el ítem de datos; y almacenar la credencial (30) en la memoria del dispositivo del usuario (12), en el que la presentación posterior de la credencial (30) al sistema de identidad digital (14) hace que el ítem de datos de la identidad digital esté disponible para un dispositivo objetivo (52) que presenta la credencial (30).

12. Un método de acuerdo con la reivindicación 11,

que comprende capturar en el dispositivo del usuario (12)

una imagen facial u otro identificador biométrico de un usuario del dispositivo del usuario (12), que se incluye en el mensaje electrónico transmitido al sistema de identidad digital (14).

13. Un dispositivo de usuario (12) que comprende:

una memoria; y

un procesador de hardware (1004) acoplado a la memoria y configurado para ejecutar instrucciones legibles por ordenador que, cuando se ejecutan en el procesador de hardware (1004), hacen que el procesador de hardware (1004):

capture un ítem de datos de un documento de identidad (10),

cree un mensaje electrónico que comprende el ítem de datos,

transmita el mensaje electrónico desde el dispositivo del usuario (12) hasta un sistema de identidad digital (14), reciba desde el sistema de identidad digital (14) un mensaje electrónico que comprende una credencial (30), que esté unida a una identidad digital que comprende el ítem de datos, se ha creado la identidad digital en el sistema de identidad digital (14) en respuesta al mensaje electrónico que comprende el ítem de datos; y

almacene la credencial (30) en la memoria, en la que la presentación posterior de la credencial (30) al sistema de identidad digital (14) hace que el ítem de datos de la identidad digital esté disponible para un dispositivo objetivo (52) que presenta la credencial (30).

14. Un medio de almacenamiento no transitorio legible por ordenador que comprende el código (1002) ejecutable por un dispositivo de usuario (12) para implementar las etapas de:

capturar un ítem desde datos de un documento de identidad (10);

crear un mensaje electrónico que comprende el ítem de datos;

transmitir el mensaje electrónico desde el dispositivo del usuario (12) hasta un sistema de identidad digital (14); recibir desde el sistema de identidad digital (14) un mensaje electrónico que comprende una credencial (30), que está unida a una identidad digital que comprende el ítem de datos, se ha creado la identidad digital en el sistema de identidad digital (14) en respuesta al mensaje electrónico que comprende el ítem de datos; y

almacenar la credencial (30) en el dispositivo del usuario (12), en el que la presentación posterior de la credencial (30) al sistema de identidad digital (14) hace que el ítem de datos de la identidad digital (14) esté disponible para un dispositivo objetivo (52) que presenta la credencial (30).