Now the App.config

InfoCard ends up getting invoked (at least in the Indigo use cases) via a custom binding in the services configuration file (app.config or web.config depending on selfhosting or was/iis hosted services)

The config file has 3 main sections required for InfoCard usage. The first is a custom binding. The binding section basically describes the protocol indigo will use to expose or talk to services in a declarative fasion. It ships with a number of default bindings for WS-I basic profile interop, WS-*, as well as some MSFT proprietary binary optimizations. You do have the ability to define a custom binding which gives you granular control over protocol. In order to use InfoCard, you seem to need to use a custom binding. Here is an example:

<bindings>
<customBinding>
<!-- Define custom binding for InfoCard. -->
<binding configurationName="InfoCardBinding">
<security authenticationMode="IssuedTokenForCertificate" contextMode="Session">
<federationParameters>
<tokenRequestParameters>
<xmlElement>
<wst:TokenType xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>
</xmlElement>
<xmlElement>
<wst:Claims xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity"  xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsid:Claim wsid:URI="http://schemas.microsoft.com/ws/2004/10/identity#E-Mail-Address"/>
</wst:Claims>
</xmlElement>
</tokenRequestParameters>
</federationParameters>
</security>
<httpTransport/>
</binding>
customBinding>
</bindings>

This basically says that the authentication mode is IssuedTokenForCertificate which I believe indicates "Use InfoCard" It then designates the parameters which will be passed into the WS-Trust RST - in this case stating that it wants a SAML assertion with email address attribute assertion

Next, we need special behavior section which is referenced from the endpoint configuration. This indicates how to find the local certificate to exchange for the SAML assertion. This required importing the certificate into my local trusted store:

<behavior configurationName="TrustedCredentials" returnUnknownExceptionsAsFaults="true">
<channelSecurityCredentials>
<serviceX509Certificate findValue="Fabrikam" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="TrustedPeople" />
</channelSecurityCredentials>
</behavior>

It's not yet clear what other credential types can be used - there seem to be many options in the core Indigo APIs, but the authenticationMode of IssuedTokenForCertificate has me a bit concerned others aren't yet supported...

Finally, a addressProperties section is required:

<addressProperties identityType="Dns" identityData="Fabrikam">
<endpointHeaders>
<dsig:X509Certificate xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">MIIDwzCCAqu....==</dsig:X509Certificate>
</endpointHeaders>
</addressProperties>

I've got to say I don't understand this at all...or more to the point, don't see how it's viable. I believe what this is doing is providing the Identity of the service itself. Since this is statically declared in the clients config, it looks like a huge distribution issue. I'm sure microsoft must have something else in mind, like fetching this over ws-mex...anyone?

That pretty much covers what is required for the client and service config files - they're pretty close to the same. Next, we'll take a look at what happens when we invoke