Tarjetas I que se muestran en el Selector de identidad de Windows CardSpace
Una tarjeta de información (o i-card ) es una identidad digital personal que las personas pueden usar en línea y es el componente clave de un metasistema de identidad. Visualmente, cada i-card tiene una imagen en forma de tarjeta y un nombre de tarjeta asociado que permite a las personas organizar sus identidades digitales y seleccionar fácilmente la que desean usar para cualquier interacción determinada. La metáfora de la tarjeta de información ha sido implementada por selectores de identidad como Windows CardSpace , DigitalMe o Higgins Identity Selector .
Un metasistema de identidad es una arquitectura interoperable para la identidad digital que permite a las personas tener y utilizar una colección de identidades digitales basadas en múltiples tecnologías, implementaciones y proveedores subyacentes. Con este enfoque, los clientes pueden seguir utilizando sus inversiones en infraestructura de identidad existentes, elegir la tecnología de identidad que funcione mejor para ellos y migrar más fácilmente de tecnologías antiguas a nuevas tecnologías sin sacrificar la interoperabilidad con otras. El metasistema de identidad se basa en los principios de "Las leyes de la identidad". [1]
Descripción general
Tarjetas de información que se muestran en el Selector de identidad de DigitalMe
Los proveedores de identidad emiten identidades digitales para usted. Por ejemplo, las empresas pueden emitir identidades para sus clientes, los gobiernos pueden avalar las identidades de sus ciudadanos, los emisores de tarjetas de crédito pueden proporcionar identidades que permitan realizar pagos, los servicios en línea pueden proporcionar datos verificados como la edad, y las personas pueden utilizar identidades autoemitidas para iniciar sesión en sitios web.
Las partes de confianza (PR) aceptan identidades por usted. Los servicios en línea que utiliza pueden aceptar identidades digitales que usted elija y usar la información que ellos proporcionen en su nombre, con su consentimiento.
El sujeto es usted mismo, la parte que controla todas estas interacciones. El sujeto puede elegir cuál de sus identidades digitales aplicables utilizar con la parte que confía.
Un selector de identidad se utiliza para almacenar, administrar y utilizar sus identidades digitales. Algunos ejemplos de selectores de identidad son Windows CardSpace de Microsoft , DigitalMe del proyecto Bandit [2] y varios tipos de selectores de identidad del proyecto Higgins de Eclipse Foundation .
Un selector de identidad realiza las siguientes tareas de gestión de identidad centradas en el usuario:
Proporciona una experiencia de usuario consistente para la autenticación (y en algunos casos otros tipos de interacciones) con un RP (también conocido como proveedor de servicios).
Proporciona una interfaz de usuario que muestra un conjunto de iconos de tarjetas de información entre los cuales el usuario selecciona su tarjeta i preferida cuando una aplicación local o una parte confiada requiere autenticación (por ejemplo, la página de inicio de sesión de un sitio web).
Proporciona una interfaz de usuario para crear y administrar tarjetas de información personal (también conocidas como autoemitidas ).
Proporciona un servicio de token de seguridad local que se utiliza para emitir tokens de seguridad para tarjetas de identificación personales.
Proporciona una interfaz de usuario para importar y exportar tarjetas de información en formatos de archivo estándar.
Se invoca mediante una extensión del navegador o mediante una aplicación cliente enriquecida local.
Un selector de identidad también puede permitir al usuario administrar (por ejemplo, crear, revisar, actualizar y eliminar tarjetas dentro de) su cartera de i-cards.
Metasistemas de identidad
Hay cinco componentes clave para un metasistema de identidad:
Una forma de representar identidades mediante reclamos. Los reclamos se incluyen en tokens de seguridad, según WS-Security .
Un medio para que los proveedores de identidad, las partes que confían y los sujetos negocien. La negociación dinámica de las reclamaciones que se entregarán y el formato de token de seguridad utilizado permite que el metasistema de identidad admita cualquier formato de token y cualquier tipo de reclamaciones necesarias para una interacción de identidad digital. La negociación se produce mediante instrucciones WS-SecurityPolicy intercambiadas mediante WS-MetadataExchange .
Un protocolo encapsulante para obtener reclamaciones y requisitos. Los protocolos WS-Trust y WS-Federation se utilizan para transportar solicitudes de tokens de seguridad y respuestas que contienen dichos tokens.
Un medio para unir las fronteras tecnológicas y organizacionales mediante la transformación de reclamaciones. Los servicios de token de seguridad (STS), tal como se definen en WS-Trust, se utilizan para transformar los contenidos y formatos de las reclamaciones.
Una experiencia de usuario consistente en múltiples contextos, tecnologías y operadores. Esto se logra mediante un software de cliente selector de identidad, como Windows CardSpace, que representa las identidades digitales que poseen los usuarios como tarjetas de identificación visuales.
Cualidades genéricas
Las tarjetas I son creadas por una entidad conocida como emisor .
Las tarjetas I muestran el nombre del emisor ( issuerName ) en una cadena de texto.
Las tarjetas I tienen una cadena de texto para identificar la tarjeta ( cardName ) que el emisor de la tarjeta establece inicialmente. Normalmente, el usuario puede editar este nombre de tarjeta.
Las tarjetas I pueden tener una imagen de fondo ( GIF o JPEG ) ( cardImage ) establecida por el emisor de la tarjeta (editable por el usuario).
En la mayoría de las i-cards el usuario puede ver el valor de las reclamaciones.
Capacidades de inicio de sesión
El gráfico utilizado para indicar el soporte de la tarjeta de información
Al utilizar i-cards, los usuarios pueden autenticarse sin necesidad de un nombre de usuario y contraseña para cada sitio web; en cambio, en los sitios que los aceptan, pueden iniciar sesión con una i-card, que puede usarse en varios sitios.
Cada tarjeta de información utiliza una clave digital distinta por pares para cada reino en el que se solicita una clave. Un reino puede ser un solo sitio o un conjunto de sitios relacionados que comparten la misma información de alcance de destino cuando se solicita una tarjeta de información. El uso de claves distintas por pares por reino significa que incluso si una persona es engañada para iniciar sesión en un sitio impostor con una tarjeta i, se usaría una clave diferente en ese sitio que en el sitio que el impostor estaba tratando de suplantar; no se divulga ningún secreto compartido.
Además, muchos selectores de identidad ofrecen un medio para detectar el phishing , ya que se comprueba el certificado HTTPS del sitio de confianza y se compara con una lista de sitios en los que el usuario ha utilizado anteriormente una tarjeta de información. Cuando se visita un nuevo sitio, se informa al usuario de que no ha utilizado previamente una tarjeta allí.
Tipos de tarjetas i
El perfil de interoperabilidad del selector de identidad v 1.5 [3] (o borrador del comité OASIS IMI v1.0) [4] especifica dos tipos de tarjetas de información que un selector de identidad debe admitir.
Tarjetas de información personal: (también llamadas tarjetas autoemitidas) le permiten emitir declaraciones sobre usted mismo a sitios que estén dispuestos a aceptarlas. Estas declaraciones pueden incluir su nombre, dirección, números de teléfono, dirección de correo electrónico, dirección web, fecha de nacimiento, sexo y una clave específica del sitio generada exclusivamente para cada sitio donde se use la tarjeta.
Tarjetas de información administrada: estas tarjetas permiten que otros proveedores de identidad que no sean usted hagan declaraciones sobre usted a sitios que estén dispuestos a aceptarlas. Estas declaraciones pueden incluir cualquier información que un proveedor de identidad solicite, que un proveedor de identidad pueda proporcionar y que usted esté dispuesto a enviar entre ellos.
El proyecto Higgins también está definiendo dos nuevos tipos de i-cards:
Las tarjetas de relación (o tarjetas R) se utilizan para establecer una relación continua entre varias partes.
Cartas de conocimiento cero (o cartas Z)
Sin embargo, el formato de la tarjeta de información permite tipos personalizados; el proyecto Bandit demostró prototipos de tarjetas administradas respaldadas por OpenID en la conferencia Novell BrainShare en marzo de 2007.
Tarjetas personales
El primer tipo de tarjetas de información personal también se introdujo como parte del software Windows CardSpace de Microsoft en noviembre de 2006. Su comportamiento también está definido por los mismos documentos que cubren las tarjetas administradas definidas por Microsoft (ver arriba).
Resumen de características:
Formato de datos : un archivo XML que contiene: un conjunto de URI de tipo de reclamación , así como los valores (definidos por el usuario) de estas reclamaciones, cardImage , un cardID único, etc. Este formato de datos se define en los documentos ISIP.
Emisor: Selector de identidad del propio usuario . Las tarjetas personales pueden describirse como autoemitidas
Génesis: Creado por el Selector de Identidad del usuario.
Reclamaciones: Se definen 15 tipos de reclamaciones predefinidas (por ejemplo, nombre, apellido, dirección de correo electrónico, etc.) en el Perfil de interoperabilidad del selector de identidad v 1.5 [3] (o Borrador del comité OASIS IMI v1.0). [4]
Autoridad: El selector de identidad del usuario es la autoridad para el conjunto de valores de reclamo del token emitido.
Flujo de datos: a pedido (por ejemplo, según lo necesite un sitio confiable), un STS local del selector de identidad crea un token de seguridad con los valores actuales.
Editabilidad: Los valores del reclamo son directamente editables por el usuario.
Origen de los datos de los atributos: el archivo XML de la tarjeta personal contiene los valores de las reclamaciones. Cuando se importan a un selector de identidad, estos valores de datos son gestionados internamente por el selector.
Tarjetas de información gestionadas
El primer tipo de tarjeta administrada se introdujo como parte del software Windows CardSpace de Microsoft en noviembre de 2006. El comportamiento, el formato de archivo y las características de interoperabilidad de este tipo de tarjetas administradas están definidos por documentos de Microsoft como el Identity Selector Interoperability Profile v 1.5 [3] (o el borrador del comité OASIS IMI v1.0; [4] consulte self-issued.info [5] para obtener una lista más completa), en combinación con estándares abiertos que incluyen WS-Trust [6] y otros.
Resumen de características:
Formato de datos: un archivo XML que contiene: punto final de red del STS, conjunto de URI de tipo de reclamo, nombre de la tarjeta, cardImage , issuerName , un cardID único, etc. El formato de archivo XML se define en los documentos ISIP.
Emisor: Un servicio de token externo de terceros (que representa a una persona u organización externa).
Génesis: una tarjeta administrada es generada por un servicio de token de seguridad que se ejecuta en un sitio de proveedor de identidad y se importa al selector de identidad del usuario.
Reclamaciones: La lista de tipos de reclamaciones admitidas (URI de tipo de reclamación) está definida por el emisor.
Autoridad: El emisor es la única autoridad sobre los valores de reclamación contenidos en el token que emite.
Flujo de datos: Las tarjetas administradas contienen una referencia de punto final de red a un STS que, cuando lo solicita el selector de identidad (usando WS-Trust, etc.), genera/proporciona un token de seguridad que contiene las reclamaciones requeridas.
Editabilidad: los datos de atributos subyacentes no son editables directamente por el usuario.
Fuente de datos del atributo: determinada por el emisor y generalmente administrada por el emisor.
Las tarjetas I emitidas por terceros pueden emplear cualquiera de cuatro métodos para que el usuario se autentique como propietario de la tarjeta:
una tarjeta de información personal (autoemitida),
un certificado X.509 (que puede ser de un dispositivo de hardware como una tarjeta inteligente o puede ser un certificado de software),
un ticket Kerberos , como los emitidos por muchas soluciones de inicio de sesión empresarial, o
un nombre de usuario y una contraseña para la tarjeta.
Los futuros selectores de identidad y proveedores de identidad también podrían implementar métodos adicionales.
Las tarjetas i administradas pueden ser auditables, no auditables o con auditoría opcional:
Las tarjetas de auditoría requieren que se revele la identidad del sitio de RP al proveedor de identidad. Esto se puede utilizar para restringir a qué sitios el proveedor de identidad está dispuesto a divulgar información.
Las tarjetas que no son de auditoría no revelarán la identidad del sitio RP al proveedor de identidad.
Las tarjetas con auditoría opcional revelarán la identidad del sitio de la Parte Confiable si la proporciona el RP, pero no requieren esta divulgación.
Tarjetas de relación
Las tarjetas de relación están siendo desarrolladas por el proyecto Higgins (ver el informe de Paul Trevithick). [7]
Resumen de características:
Formato de datos: Una tarjeta administrada que admite una reclamación de recurso-udi.
Reclamos admitidos: al igual que todas las tarjetas administradas (o personales), las tarjetas r incluyen una lista de tipos de reclamos admitidos (expresados como URI) según lo definido por el emisor. Este conjunto define el conjunto máximo de reclamos que el emisor incluirá en su token de seguridad generado. Estos reclamos se heredan de la tarjeta ISIP-m subyacente en la que se basa y se utilizan para los mismos fines. Más allá de las tarjetas administradas, el reclamo "meta" resource-udi proporciona una referencia a un conjunto de atributos.
Autoridad: El emisor es la autoridad para el conjunto de valores de reclamo del token emitido (como en una tarjeta administrada o personal normal).
Editabilidad: Los valores de los atributos subyacentes (a los que hace referencia la reclamación resource-udi) pueden ser editables por partes distintas del emisor.
Atributos admitidos: el valor de una reclamación resource-udi de una tarjeta r es un UDI de entidad [8] (URI) que "apunta a" una entidad de datos (que representa una persona, una organización u otro objeto). El conjunto de atributos de esta entidad de datos es distinto de (aunque normalmente es un superconjunto de) las "reclamaciones admitidas" mencionadas anteriormente.
Confianza en el modelo de datos de Higgins
En términos conceptuales, una tarjeta administrada es esencialmente un "puntero" fácil de usar para los humanos que apunta a un servicio de tokens, un servicio web (por ejemplo, un STS ) desde el que se pueden solicitar tokens de seguridad. Un token de seguridad es un conjunto de afirmaciones de atributos (también conocidas como afirmaciones) sobre alguna parte que está firmada criptográficamente por el emisor (el servicio de tokens actúa como autoridad). Una tarjeta r contiene un segundo "puntero" que apunta a una entidad de datos cuyos valores de atributos (i) son compartidos por todas las partes de la tarjeta r y (ii) forman los atributos subyacentes que son consumidos por el STS del emisor de la tarjeta r y proporcionan los valores de las afirmaciones que realiza este STS. Al incluir este segundo "puntero" en la tarjeta r, los titulares de la tarjeta r tienen el potencial de acceder y actualizar un subconjunto de estos atributos subyacentes. El emisor de la tarjeta mantiene una política de control de acceso para controlar quién tiene qué nivel de acceso.
Este segundo puntero es un UDI de entidad [8] —una referencia a un objeto de entidad en el modelo de datos de contexto de Higgins. [9] Los UDI de entidad se pueden desreferenciar y se puede acceder a los atributos de la entidad subyacente mediante el servicio de atributos de identidad del proyecto Higgins . [10] Una vez resuelto, los consumidores de este servicio pueden inspeccionar y potencialmente modificar los atributos de la entidad, así como obtener su esquema como se describe en el lenguaje de ontología web (OWL).
Además de los valores de atributos de identidad básicos, como cadenas y números, la entidad de datos a la que hace referencia una tarjeta r puede tener valores de atributos complejos que consisten en agregados de tipos de atributos básicos, así como enlaces UDI a otras entidades.
Reclamos
Además de utilizarse para iniciar sesión en sitios, las tarjetas de información también pueden facilitar otros tipos de interacciones. El modelo de tarjeta de información proporciona una gran flexibilidad porque las tarjetas se pueden utilizar para transmitir cualquier información de un proveedor de identidad a una parte que confía que tenga sentido para ambos y que la persona esté dispuesta a divulgar. Los elementos de datos que se incluyen en las tarjetas de información se denominan reclamaciones.
Un posible uso de las reclamaciones es la verificación de la edad en línea, en la que los proveedores de identidad proporcionan tarjetas de prueba de edad y los proveedores de servicios las aceptan para fines tales como la venta de vino en línea; también se podrían verificar otros atributos. Otro uso es el pago en línea , en el que los comerciantes podrían aceptar tarjetas de pago en línea de los emisores de pagos, que contengan solo la información mínima necesaria para facilitar el pago. Las declaraciones de roles incluidas en las reclamaciones se pueden utilizar para las decisiones de control de acceso de las partes que confían.
Interoperabilidad y licencias
Los protocolos necesarios para construir los componentes del Metasistema de Identidad pueden ser utilizados por cualquier persona para cualquier propósito sin costo de licencia y se pueden construir implementaciones interoperables utilizando únicamente documentación disponible públicamente. Microsoft, [11] IBM, [12] y otros han emitido promesas de patentes que garantizan que los protocolos subyacentes al Metasistema de Identidad puedan ser utilizados libremente por todos.
Las tarjetas de información definidas por el perfil de interoperabilidad del selector de identidad v 1.5 [3] (o borrador del comité OASIS IMI v1.0) [4] se basan en estándares de comunicación abiertos e interoperables. Docenas de empresas y proyectos han creado componentes de tarjetas de información interoperables para plataformas como Windows, Mac OS y Linux, además de una implementación de prototipo para teléfonos. En conjunto, estos componentes implementan un metasistema de identidad interoperable. Las tarjetas de información se pueden utilizar para proporcionar identidades tanto para sitios web como para aplicaciones de servicios web.
OSIS [13] y Burton Group [14] han patrocinado varios eventos de pruebas de interoperabilidad para tarjetas de información , uno de ellos en Interop, en la Conferencia European Catalyst de octubre de 2007 en Barcelona [15] y el más reciente en RSA 2008. Estos eventos están ayudando a garantizar que los diferentes componentes de software de tarjetas de información que están construyendo los numerosos participantes en el Metasistema de Identidad funcionen bien juntos.
Los protocolos necesarios para crear implementaciones de tarjetas de información basadas en el perfil de interoperabilidad del selector de identidad v 1.5 [3] (o borrador del comité OASIS IMI v1.0) [4] pueden ser utilizados por cualquier persona para cualquier propósito sin costo y se pueden crear implementaciones interoperables utilizando únicamente documentación disponible públicamente. Microsoft, [11] IBM, [12] y otros han emitido promesas de patentes que garantizan que esta tecnología de tarjetas de información esté disponible gratuitamente para todos.
En junio de 2008, líderes de la industria como Equifax, Google, Microsoft, Novell, Oracle, PayPal y otros crearon la Information Card Foundation con el fin de promover el uso de la metáfora de la tarjeta de información como un componente clave de una capa de identidad abierta, interoperable, libre de regalías y centrada en el usuario que abarque tanto la empresa como Internet.
En su informe sobre Interop en la Conferencia Catalyst de junio de 2007 en San Francisco, [16] el analista Bob Blakley escribió:
El evento de interoperabilidad fue un hito en la maduración de la tecnología de identidad centrada en el usuario. Antes del evento, había algunas especificaciones, un producto comercial y varios proyectos de código abierto. Después del evento, se puede decir con precisión que existe un metasistema de identidad en funcionamiento.
Historia de la terminología
El término "tarjeta de información" fue introducido por Microsoft en mayo de 2005 como nombre para la metáfora de la tarjeta de información visual que se introduciría en su próximo software Windows CardSpace. Hasta principios de 2006, las tarjetas de información también se denominaban a veces con el nombre en código "InfoCard", que no era un nombre que estuviera disponible para que todo el mundo lo usara libremente. El nombre "tarjeta de información" se eligió específicamente como uno que estaría disponible para que todo el mundo lo usara libremente, independientemente de cualquier producto o implementación. El nombre "tarjeta de información" no es una marca registrada y es tan genérico que no se puede registrar como marca registrada.
El término i-card se introdujo en la conferencia Berkman/MIT Identity Mashup del 21 de junio de 2006. [17] [18] La intención era definir un término que no estuviera asociado con ninguna marca de la industria ni con ninguna otra propiedad intelectual o artefacto. En ese momento, Microsoft aún no había terminado de aplicar la Promesa de especificación abierta [11] a los protocolos subyacentes a Windows CardSpace y también existía un malentendido de que el término tarjeta de información no estaba disponible libremente para su uso por parte de todos, por lo que, para ser conservadores, se introdujo el término i-card.
Mike Jones, de Microsoft, explicó a los participantes de una sesión en IIW 2007b [19] que Microsoft siempre tuvo la intención de que el término tarjeta de información se utilizara de forma genérica para describir todo tipo de tarjetas de información y que fuera de libre uso para todos, e intentó corregir el malentendido anterior de que el término podría aplicarse únicamente a los tipos de tarjetas de información definidos originalmente por Microsoft. Sostuvo que la industria estaría mejor servida si todos utilizaran el término común tarjeta de información, en lugar de tener dos términos en uso con el mismo significado, ya que no existe ninguna razón legal o técnica para términos diferentes. En este caso, el término i-card se convertiría simplemente en la forma abreviada de tarjeta de información, al igual que e-mail se ha convertido en la forma abreviada de correo electrónico.
Implementaciones de software
DACS – RP de código abierto y tarjeta de información STS escrita en C
Proyecto Higgins : configuración de la implementación del Selector de identidad
^ "Modelo de datos de contexto 1.0 - Eclipsepedia". wiki.eclipse.org .
^ "Servicio de atributos de identidad 1.0 - Eclipsepedia". wiki.eclipse.org .
^ abc "Promesa de especificación abierta". www.microsoft.com .
^ ab "IBM Open Source Portal". 8 de octubre de 2007. Archivado desde el original el 8 de octubre de 2007.
^ "Sistemas de identidad de código abierto OSIS". osis.idcommons.net .
^ "Gartner para profesionales técnicos - Investigación de TI - Gartner Inc". www.burtongroup.com . Archivado desde el original el 18 de diciembre de 2008 . Consultado el 27 de noviembre de 2007 .
^ Centro de usuarios de Osis
^ Recapitulando el C
^ "Notas de la reunión de la conferencia MIT Identity Mashup". Archivado desde el original el 3 de marzo de 2009. Consultado el 25 de septiembre de 2010 .
^ "Más sobre tarjetas I y nombres I". 28 de julio de 2006.
^ "Iiw2007b - IIW". iiw.idcommons.net .
Clique Space: otra mirada a la identidad, Owen Thomas, noviembre de 2010.
Parity ofrece gestión de identidad en línea gratuita – Artículo de CNET de octubre de 2008 escrito por Robert Vamosi
La visión de Microsoft para un metasistema de identidad, Michael B. Jones, mayo de 2005.
Las leyes de la identidad, Kim Cameron, mayo de 2005.
Fundamento del diseño detrás de la arquitectura del metasistema de identidad, Kim Cameron y Michael B. Jones, enero de 2006.
7 leyes de identidad: el caso de leyes de identidad integradas en la privacidad en la era digital, Ann Cavoukian, Comisionada de Información y Privacidad de Ontario, octubre de 2006.
Recursos adicionales
Los líderes tecnológicos prefieren las tarjetas de identificación en línea a las contraseñas: artículo del New York Times del 24 de junio de 2008 que anuncia la fundación de la tarjeta de información
Perfil de interoperabilidad del selector de identidad, Arun Nanda, abril de 2007.
Perfil de interoperabilidad del selector de identidad v 1.5
Borrador del Comité OASIS IMI v1.0
Guía del implementador del perfil de interoperabilidad del selector de identidad V1.0, Microsoft Corporation y Ping Identity Corporation, abril de 2007.
Una guía para utilizar el perfil de interoperabilidad del selector de identidad V1.0 en aplicaciones web y navegadores, Michael B. Jones, abril de 2007.
Fundamento del diseño detrás de la arquitectura del metasistema de identidad, Kim Cameron y Michael B. Jones, enero de 2006.
Patrones para tarjetas de información de apoyo en sitios web: tarjetas personales para registrarse e iniciar sesión, Bill Barnes, Garrett Serack y James Causey, agosto de 2007.
Promesa de especificación abierta de Microsoft, mayo de 2007.
Compromiso de especificaciones de interoperabilidad de IBM, julio de 2007.
Enlaces externos
Tarjeta de información de la Fundación Archivado el 4 de febrero de 2013 en Wayback Machine.
Anuncio del icono de la tarjeta de información, junio de 2007.
Sistemas de identidad de código abierto (OSIS) Archivado el 16 de mayo de 2008 en Wayback Machine
