Interop Use Cases

A list of interoperability use cases. If you have additional cases, please do add them here. We use the term "use case" loosely here; our point is to communicate potential interoperability challenges, and why they are important.

Scenarios from Mike Jones

Our interoperability use cases should include doing interop among software implementing components of the identity metasystem enabled by WS-Trust, WS-MEX, WS-SecurityPolicy, etc. (including the HTML relying party encodings). The scenarios should include uses of self-issued and managed cards, both through STS-based and Web-based relying parties, with managed card authentication being accomplished via the four methods supported by CardSpace V1 (self-issued card, X.509 cert, Kerberos ticket, username/password), using both symmetric and asymmetric bindings, where supported. The web-based relying party scenarios should include uses of both the Object and the XHTML HTML extensions. Dynamic detection of client-side and/or server-side support for Information Cards should be tested. And we should make sure that the managed card support is tested not just with SAML tokens, but also with other token types, including completely non-standard tokens that the identity selector could not have possibly have known about in advance. Display token support should be exercised.

Need for card format interoperability

Assumption: card is distributed over the wire (e.g. relying party offers user to download card to the client for subsequent use) or via a file on a USB drive. Similar use cases exist if the card is distributed differently.

Problem 1: To achieve cross/implementation card import/export relying parties will have either:

• to support only the data representable in Microsoft's card format (and thus couldn't take advantage of, say, OpenID support in Higgins)
• to deal with the customer support issues if certain cards could not be successfully imported into CardSpace or other selectors (for instance, only into Higgins)
• potentially provide multiple download links ("Dear customer, if you use CardSpace, click here; if you use Higgins, click here, if you use selector X, click here..."), or choose to use cards that all relevant selectors can understand.

Problem 2: If Higgins or other selectors extend the format to support additional requirements, and if CardSpace only understands a subset, how does a site communicate those two cases to their end users, and/or deal with customer support issues?

Some Scenarios from Tony Nadalin

So what I would like to see as a main theme of this interop would be the interopability between identity systems, CardSpace, Higgins, SAML, OpenID, Kerberos, X509, etc. The current interop matrix focus around various CardSpace configurations, supported tokens, etc using a single protocol and not mixing and matching what folks have today or will have. So some very high level scenarios would be:

1. Authenticate to a CardSpace enabled relying party using an OpenID URL identifier
2. Authenticate to a OpenID enabled relying party with a CardSpace card over CardSpace protocol (different card types with different tokens)
3. Cardspace enabled SAML Attribute Authority for attribute exchange
4. OpenID enabled SAML Attribute Authority for attribute exchange
5. Authenticate to a Cardspace enabled relying party with Higgins iCard
6. Higgins enabled SAML Attribute Authority context provider
7. Authenticate to a Higgins enabled relying party with OpenID URL identifier
8. and so on ...