Interoperability demonstrations

This page represents thoughts about what developers should implement for purposes of demonstrating interoperability among various InfoCard systems and components. You can think of it as a nested sequence of minimun requirements if you wish. It is generally organized according to the number of computers that must be involved for the demonstration and the amount of code that needs to be written.

The purpose here is to allow developers to develop partial implementations and be able to provide useful demonstrations before having a "full" implementation. Although there may be some cases where code is developed solely for demonstration purposes and later discarded in a more complete implementation, an attempt is made to minimize such circumstances.

Client (Identity selector) and relying party

• Log in to relying party with only self-asserted claims. At a minimum:
  • Name
  • Email address
  • Private personal identifier (PPID)

Managed cards via LDAP

• Log in to relying party with claims that come from an LDAP server
  • Authentication to the LDAP server is via LDAP BIND operation
    • (This may be code that is eventually discarded)

Simplest possible use for normal cases

• For second and subsequent visits, be able to log in with just one click
  • This seems to require that the client be able to remember the last card used at a site (like Microsoft CardSpace does) and present an identity selector with that card already selected
    • It's also part of an anti-phishing defense
• Ability to use same card for multiple, unrelated relying parties

One card -- Multiple platforms

• Ability to export a card from one platform and import it into another
  • Windows
    • IE, Firefox
  • Macintosh
    • Safari, Firefox
  • Linux, Firefox

OSIS Main Page