Articulo de referencia

Tarjeta informativa

Tarjetas de identificación mostradas en el selector de identidad de Windows CardSpace Una tarjeta de información (o i-card ) es una identidad digital personal que las personas p...

Tarjetas de identificación mostradas 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 el componente clave de un metasistema de identidad. Visualmente, cada i-card tiene una imagen en forma de tarjeta y un nombre asociado que permiten a las personas organizar sus identidades digitales y seleccionar fácilmente la que desean usar para cada interacción. 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 un conjunto de identidades digitales basadas en múltiples tecnologías, implementaciones y proveedores subyacentes. Mediante este enfoque, los clientes pueden seguir utilizando sus inversiones existentes en infraestructura de identidad, elegir la tecnología de identidad que mejor se adapte a sus necesidades y migrar más fácilmente de tecnologías antiguas a nuevas 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 informativas que se muestran en DigitalMe Identity Selector

En las interacciones de identidad digital que utilizan tarjetas informativas, participan tres tipos de personas :

  • Los proveedores de identidad emiten identidades digitales. Por ejemplo, las empresas pueden emitir identidades a sus clientes, los gobiernos pueden avalar la identidad de sus ciudadanos, las emisoras 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 usar identidades autoemitidas para iniciar sesión en sitios web.
  • Las partes confiables (PR) aceptan identidades en su nombre. Los servicios en línea que usted utiliza pueden aceptar identidades digitales que usted elija y usar la información que proporcionan 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 otra parte.

Selectores

Implementación de un selector de identidad por parte de Microsoft en Windows CardSpace

Un selector de identidad se utiliza para almacenar, administrar y usar sus identidades digitales. Ejemplos de selectores de identidad son Windows CardSpace de Microsoft , DigitalMe del Bandit Project , [ 2 ] y varios tipos de selectores de identidad del proyecto Higgins de la Fundación Eclipse .

Un selector de identidades realiza las siguientes tareas de gestión de identidades 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 que el usuario selecciona su tarjeta de información preferida cuando una aplicación local o una parte confiable (por ejemplo, la página de inicio de sesión de un sitio web) requiere autenticación.
  • Proporciona una interfaz de usuario para crear y gestionar tarjetas de información personal (también conocidas como tarjetas autoemitidas ).
  • Proporciona un servicio local de tokens de seguridad que se utiliza para emitir los tokens de seguridad para las tarjetas de identificación personales (i-cards).
  • 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 gestionar (por ejemplo, crear, revisar, actualizar y eliminar tarjetas dentro de) su cartera de tarjetas de identidad.

Metasistemas de identidad

Un metasistema de identidad consta de cinco componentes clave:

  • Una forma de representar identidades mediante reclamaciones. Las reclamaciones se almacenan en tokens de seguridad, según WS-Security .
  • Un mecanismo para que los proveedores de identidad, las partes que confían en la información y los sujetos negocien. La negociación dinámica de las declaraciones que se entregarán y el formato del token de seguridad utilizado permite que el metasistema de identidad admita cualquier formato de token y cualquier tipo de declaración necesaria para una interacción de identidad digital. La negociación se realiza mediante declaraciones WS-SecurityPolicy intercambiadas a través de WS-MetadataExchange .
  • Un protocolo de encapsulación para obtener reclamaciones y requisitos. Los protocolos WS-Trust y WS-Federation se utilizan para transmitir solicitudes de tokens de seguridad y respuestas que contienen dichos tokens.
  • Un método para superar las barreras tecnológicas y organizativas mediante la transformación de reclamaciones. Los servicios de tokens de seguridad (STS), tal como se definen en WS-Trust, se utilizan para transformar el contenido y el formato de las reclamaciones.
  • Una experiencia de usuario consistente en múltiples contextos, tecnologías y operadores. Esto se logra mediante software cliente de selección de identidad, como Windows CardSpace, que representa las identidades digitales de los usuarios como tarjetas de identidad 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 establece inicialmente el emisor de la tarjeta. Normalmente, este nombre de tarjeta es editable por el usuario.
  • 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 tarjetas i-card, 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

Mediante las tarjetas i-card, los usuarios pueden autenticarse sin necesidad de un nombre de usuario y una contraseña para cada sitio web; en su lugar, en los sitios que las aceptan, pueden iniciar sesión con una tarjeta i-card, que puede utilizarse en varios sitios.

Cada tarjeta de información utiliza una clave digital distinta para cada dominio donde se solicita. Un dominio puede ser un sitio único o un conjunto de sitios relacionados que comparten la misma información de alcance al solicitar una tarjeta de información. El uso de claves distintas por dominio implica que, incluso si una persona es engañada para iniciar sesión en un sitio fraudulento con una tarjeta de información, se utilizará una clave diferente en ese sitio que en el sitio que el impostor intentaba suplantar; no se divulga ningún secreto compartido .

Además, muchos selectores de identidad ofrecen un método de detección de phishing , donde se verifica el certificado HTTPS del sitio web de la parte confiable y se compara con una lista de los sitios en los que el usuario ha utilizado previamente una tarjeta de información. Cuando se visita un sitio nuevo, se informa al usuario que no ha utilizado una tarjeta allí con anterioridad.

Tipos de tarjetas de identificación

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) estas tarjetas le permiten proporcionar información personal a los sitios web que las acepten. Esta información puede incluir su nombre, dirección, números de teléfono, dirección de correo electrónico, dirección web, fecha de nacimiento, género y una clave específica para cada sitio donde se utilice la tarjeta.
  • Tarjetas de Información Gestionada: Estas tarjetas permiten que otros proveedores de identidad, además de usted, hagan declaraciones sobre usted a sitios web que acepten dichas declaraciones. 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 compartir entre ellos.

El proyecto Higgins también está definiendo dos nuevos tipos de tarjetas i:

  • Las tarjetas de relación (o tarjetas R) se utilizan para establecer una relación continua entre varias partes.
  • Tarjetas de conocimiento cero (o tarjetas Z)

Sin embargo, el formato de la Tarjeta de Información permite tipos personalizados; el proyecto Bandit presentó prototipos de tarjetas gestionadas respaldadas por OpenIDs en la conferencia Novell BrainShare en marzo de 2007.

Tarjetas personales

Las primeras tarjetas de información personal también se introdujeron como parte del software Windows CardSpace de Microsoft en noviembre de 2006. Su comportamiento también se define en los mismos documentos que cubren las tarjetas administradas definidas por Microsoft (ver más arriba).

Resumen de características:

  • El formato de datos es 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 está definido en los documentos ISIP.
  • Emisor: El propio selector de identidad del usuario . Las tarjetas personales pueden describirse como autoemitidas.
  • Génesis: Creado por el selector de identidad del usuario.
  • Reclamaciones: En el Perfil de Interoperabilidad del Selector de Identidad v 1.5 [ 3 ] (o en el Borrador del Comité OASIS IMI v1.0) se definen 15 tipos de reclamaciones predefinidas (p. ej., nombre, apellido, dirección de correo electrónico, etc. ). [ 4 ]
  • Autoridad: El selector de identidad del usuario es la autoridad para el conjunto de valores de reclamación del token emitido.
  • Flujo de datos: Bajo demanda (por ejemplo, según lo necesite un sitio que dependa de él), un STS local al selector de identidad crea un token de seguridad con los valores actuales.
  • Editabilidad: Los valores de las reclamaciones 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. Al importarlos 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 Identity Selector Interoperability Profile v 1.5 [ 3 ] (o OASIS IMI v1.0 Committee Draft; [ 4 ] consulte self-issued.info [ 5 ] para obtener una lista más completa), en combinación con estándares abiertos, incluidos 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 reclamación, nombre de la tarjeta, cardImage , issuerName , un cardID único, etc. El formato del archivo XML está definido en los documentos ISIP.
  • Emisor: Un servicio de tokenización externo, de terceros (que representa a una persona u organización externa).
  • Génesis: Un servicio de tokens de seguridad que se ejecuta en el sitio de un proveedor de identidad genera una tarjeta gestionada, la cual se importa al selector de identidad del usuario.
  • Reclamaciones: La lista de tipos de reclamaciones admitidos (URI de tipos de reclamaciones) la define 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 gestionadas contienen una referencia a un punto final de red que apunta a un STS que, cuando lo solicita el Selector de Identidad (mediante WS-Trust, etc.), genera/proporciona un token de seguridad que contiene las declaraciones requeridas.
  • Editabilidad: Los datos de los atributos subyacentes no son directamente editables por el usuario.
  • Fuente de datos de los atributos: Determinada por el emisor y, por lo general, gestionada por el emisor.

Las tarjetas de identificación emitidas por terceros pueden emplear cualquiera de los cuatro métodos para que el usuario se autentique como titular de la tarjeta:

  • una Tarjeta de Información Personal (autoemitida),
  • un certificado X.509 (que puede provenir 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 empresariales, o
  • un nombre de usuario y una contraseña para la tarjeta.

Los futuros selectores y proveedores de identidad también podrían implementar métodos adicionales.

Las tarjetas i-card gestionadas pueden ser auditables, no auditables o con auditoría opcional:

  • Las tarjetas de auditoría requieren que se revele la identidad del sitio RP al proveedor de identidad. Esto puede utilizarse para restringir a qué sitios está dispuesto el proveedor de identidad a divulgar información.
  • Las tarjetas que no realizan auditorías no revelarán la identidad del sitio RP al proveedor de identidad.
  • Las tarjetas con opción de auditoría revelarán la identidad del sitio del Entidad Confiable si esta la proporciona, pero no exigen dicha revelación.

Tarjetas de relación

El proyecto Higgins está desarrollando tarjetas de relaciones (véase el informe de Paul Trevithick). [ 7 ]

Resumen de características:

  • Formato de datos: Una tarjeta gestionada que admite una reclamación resource-udi.
  • Reclamaciones admitidas: Al igual que todas las tarjetas gestionadas (o personales), las r-cards incluyen una lista de tipos de reclamaciones admitidas (expresadas como URI) según lo define el emisor. Este conjunto define el conjunto máximo de reclamaciones que el emisor incluirá en su token de seguridad generado. Estas reclamaciones se heredan de la ISIP-m-card subyacente en la que se basa y se utilizan para los mismos fines. Además de las tarjetas gestionadas, la reclamación "meta" resource-udi proporciona una referencia a un conjunto de atributos.
  • Autoridad: El emisor es la autoridad para el conjunto de valores de reclamación del token emitido (como en una tarjeta gestionada o personal normal).
  • Editabilidad: Los valores de los atributos subyacentes (a los que hace referencia la declaración resource-udi) pueden ser editados por partes distintas del emisor.
  • Atributos admitidos: El valor de la declaración resource-udi de una r-card es un UDI de entidad [ 8 ] (URI) que "apunta a" una entidad de datos (que representa a una persona, organización u otro objeto). El conjunto de atributos de esta entidad de datos es distinto de (aunque generalmente es un superconjunto de) las "declaraciones admitidas" mencionadas anteriormente.

Dependencia del modelo de datos de Higgins

Conceptualmente, una tarjeta gestionada es esencialmente un "puntero" fácil de usar para el usuario que apunta a un Servicio de Tokens (un servicio web , por ejemplo, un STS ) desde el cual se pueden solicitar tokens de seguridad. Un token de seguridad es un conjunto de afirmaciones de atributos (también llamadas reclamaciones) sobre una parte, firmadas criptográficamente por el emisor (el servicio de tokens que actúa como autoridad). Una tarjeta gestionada 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 gestionada y (ii) forman los atributos subyacentes que consume el STS del emisor de la tarjeta gestionada y proporcionan los valores de las reclamaciones que realiza dicho STS. Al incluir este segundo "puntero" en la tarjeta gestionada, los titulares de la tarjeta gestionada tienen la posibilidad 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 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 utilizando 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 tal como se describe en el lenguaje de ontología web (OWL).

Además de los valores básicos de atributos de identidad, como cadenas de texto y números, la entidad de datos a la que se refiere 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 web, las Tarjetas de Información también facilitan otros tipos de interacciones. El modelo de Tarjeta de Información ofrece gran flexibilidad, ya que permite transmitir cualquier información de un Proveedor de Identidad a una Parte Confiable que sea relevante para ambas partes y que la persona esté dispuesta a compartir. Los elementos de datos que contienen las i-cards se denominan Reclamaciones.

Un posible uso de las reclamaciones es la verificación de edad en línea, donde los proveedores de identidad emiten tarjetas de prueba de edad y las partes confiables las aceptan para fines como la venta de vino en línea; también se podrían verificar otros atributos. Otro uso es el pago en línea , donde los comercios podrían aceptar tarjetas de pago de emisores de pago, que contengan solo la información mínima necesaria para facilitar el pago. Las declaraciones de rol que contienen las reclamaciones pueden ser utilizadas por las partes confiables para tomar decisiones de control de acceso.

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 crear implementaciones interoperables utilizando únicamente la documentación disponible públicamente. Microsoft, [ 11 ] IBM, [ 12 ] y otras empresas han emitido promesas de patente que garantizan que los protocolos subyacentes al Metasistema de Identidad pueden 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 el Borrador del Comité OASIS IMI v1.0) [ 4 ] se basan en estándares de comunicación abiertos e interoperables. Decenas de empresas y proyectos han desarrollado componentes de tarjetas de información interoperables para plataformas como Windows, Mac OS y Linux, además de una implementación prototipo para teléfonos. En conjunto, estos componentes implementan un Metasistema de Identidad interoperable. Las tarjetas de información pueden utilizarse para proporcionar identidades tanto para sitios web como para aplicaciones de servicios web.

OSIS [ 13 ] y el Grupo Burton [ 14 ] han patrocinado varios eventos de pruebas de interoperabilidad para tarjetas de información (i-cards). Uno de ellos tuvo lugar en la conferencia Interop de la European Catalyst Conference de Barcelona en octubre de 2007 [ 15 ] , y el más reciente en RSA 2008. Estos eventos contribuyen a garantizar que los diferentes componentes de software de las tarjetas de información, desarrollados por los numerosos participantes del Metasistema de Identidad, funcionen correctamente en conjunto.

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 el Borrador del Comité OASIS IMI v1.0) [ 4 ] pueden ser utilizados por cualquier persona para cualquier propósito sin costo alguno, y las implementaciones interoperables pueden crearse utilizando únicamente la documentación disponible públicamente. Microsoft, [ 11 ] IBM, [ 12 ] y otros han emitido promesas de patente , lo que garantiza 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 la interoperabilidad en la Conferencia Catalyst de junio de 2007 en San Francisco, [ 16 ] el analista Bob Blakley escribió:

El evento de interoperabilidad marcó un hito en la maduración de la tecnología de identidad centrada en el usuario. Antes del evento, existían algunas especificaciones, un producto comercial y varios proyectos de código abierto. Tras el evento, se puede afirmar con certeza que existe un metasistema de identidad en pleno funcionamiento.

Historia de la terminología

Microsoft introdujo el término «tarjeta de información» en mayo de 2005 para referirse a la metáfora visual de la tarjeta de información que se incorporaría en su próximo software Windows CardSpace. Hasta principios de 2006, las tarjetas de información también se conocían a veces con el nombre en clave «InfoCard», que no era un nombre de libre uso. El nombre «tarjeta de información» se eligió específicamente por su libre disponibilidad, independientemente del producto o la implementación. El nombre «tarjeta de información» no está registrado como marca comercial y es tan genérico que no puede ser registrado.

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 registrada 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 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, y trató de corregir el malentendido anterior de que el término pudiera aplicarse solo a los tipos de tarjetas de información definidos originalmente por Microsoft. Argumentó que sería mejor para la industria que todos usaran el término común tarjeta de información, en lugar de tener dos términos con el mismo significado, ya que no existe ninguna razón legal o técnica para usar 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

Véase también

Referencias

  1. "Las leyes de la identidad" . Microsoft. 5 de junio de 2011. Archivado del original el 5 de junio de 2011.
  2. "DigitalMe – Bandit – Trac" . 13 de octubre de 2008. Archivado del original el 13 de octubre de 2008.
  3. 1 2 3 4 5 Perfil de interoperabilidad del selector de identidad v 1.5 Microsoft
  4. 1 2 3 4 5 Especificaciones oasis-open.org
  5. "Mike Jones: autoemitido » Se publican versiones actualizadas de los documentos de perfil de la Tarjeta de Información" . self-issued.info . 
  6. WS Trust xmlsoap.org Febrero de 2005
  7. Webmaster. "Proyectos archivados" . www.eclipse.org .
  8. 1 2 http://parity.com/udi
  9. "Modelo de datos de contexto 1.0 - Eclipsepedia" . wiki.eclipse.org .
  10. "Servicio de atributos de identidad 1.0 - Eclipsepedia" . wiki.eclipse.org .
  11. 1 2 3 "Promesa de especificación abierta" . www.microsoft.com .
  12. 1 2 "Portal de código abierto de IBM" . 8 de octubre de 2007. Archivado del original el 8 de octubre de 2007.
  13. "OSIS Sistemas de identidad de código abierto" . osis.idcommons.net . Archivado del original el 1 de agosto de 2008. Consultado el 31 de julio de 2008 .
  14. "Gartner para profesionales técnicos - Investigación de TI - Gartner Inc." . www.burtongroup.com . Archivado del original el 18 de diciembre de 2008 . Consultado el 27 de noviembre de 2007 .
  15. Centro de usuarios de Osis
  16. Recapitulando la C
  17. "Notas de la reunión de la conferencia MIT Identity Mashup" . Archivado del original el 3 de marzo de 2009. Consultado el 25 de septiembre de 2010 .
  18. "Más información sobre las tarjetas I y los nombres I" . 28 de julio de 2006.
  19. «Iiw2007b - IIW» . iiw.idcommons.net .
  • Espacio de camarilla: otra mirada a la identidad , Owen Thomas, noviembre de 2010.
  • Parity ofrece gestión de identidad en línea gratuita Artículo de Robert Vamosi en CNET , octubre de 2008.
  • 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.
  • Fundamentos del diseño de la arquitectura del metasistema de identidad , Kim Cameron y Michael B. Jones, enero de 2006.
  • 7 leyes de identidad: Argumentos a favor de leyes de identidad que incorporen 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 Information Card.
  • 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 de implementación del perfil de interoperabilidad del selector de identidad V1.0 , Microsoft Corporation y Ping Identity Corporation, abril de 2007.
  • Guía para el uso del perfil de interoperabilidad Identity Selector V1.0 en aplicaciones web y navegadores , Michael B. Jones, abril de 2007.
  • Fundamentos del diseño de la arquitectura del metasistema de identidad , Kim Cameron y Michael B. Jones, enero de 2006.
  • Patrones para tarjetas de información complementarias 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 IBM con las especificaciones de interoperabilidad , julio de 2007.
  • Fundación de Tarjetas Informativas Archivada el 4 de febrero de 2013 en Wayback Machine
  • Anuncio del icono de la tarjeta informativa , junio de 2007.
  • Sistemas de identidad de código abierto (OSIS) Archivado el 16 de mayo de 2008 en Wayback Machine