Have you created your first self-issued card yet?  Please see my first posting for instruction.   Would you like to create, delete a bunch of cards programmatically?  I have a good news and/or a bad news.  The bad (or good) news is – you can’t. There is no programmatic access to InfoCard store, period. The cards that represent your digital identities are very closely guarded; a virus running in a user context won’t be able to enumerate cards, delete cards, or creating cards.  User MUST be in control on card lifecycle management (create/delete/update,etc), as well as the release of token to the RP. User is an integral part of Identity metasystem. InfoCard as an Identity Selector interacts with the user closely.  For those of you who are looking for InfoCard OM, well sorry, it is virtually non-existence.


So, how do you trigger InfoCard UX on the client to appear?  It starts from a Relying Party.  As an RP (and also an IP), you’ll get to choose what authentication mechanism you would like to use to grant access to your resource(s).  For example, one could use UserNamePassword over SSL, or Kerberos, or X509Certificate, or others.  The authentication mechanism that will trigger InfoCard experience on the client is called “IssuedToken”.   All of these requirements are expressed in WS-SecurityPolicy.   

So, here is the flow:

1.      The client application gets a RP’s policy (which includes authentication mechanism). This can be done during design time or runtime. The protocol used is WS-MetadataExchange.

2.      Based on this policy (to be accurate, policy is included in WSDL), the client has enough information on how to communicate to the web service (which, in this case, is RP’s). At this point, no connection has been established yet.

3.      The client library parses the security policy requirements (along with other binding requirements). It learns that it requires “IssuedToken”; the library, then, will call InfoCard System to satisfy the token request, passes along the RP’s security policy requirement (such as issuer, tokenType, claim set, etc)

4.      InfoCard System returns the token to the client library (after getting the requested token from IP using WS-Trust protocol)

5.      The client library now is ready to communicate to the RP’s service. The issued token will be included as part of WS-Security in the initial communication.


Hmm… that sounds complicated, …. too many protocols to learn… ?  Not really, with Indigo – you’ll see that this amounts to only a few lines of code.  In fact, a client app that normally uses UserName/Password, or Kerberos, could suddenly support InfoCard without (or little) code modification.


In the next posting, let’s create (1) a client application and (2) RP’s service. The Identity Provider role will be played by InfoCard Local IP/STS.   First, we’ll build a simplest Indigo hello world, and then we’ll enhance it with InfoCard.  We’ll also introduce a few InfoCard concepts along the way.  Sound good? Please stay tuned..