In WCF there's a knob which you can turn to configure service credential propagation semantics.
It's called negotiateServiceCredential and is present in bindings/<bindingOfChoice>/binding/security/message/@negotiateServiceCredential in the WCF configuration schema.
This would be a possible use of it, considering only the bindings section of the WCF configuration file:
<bindings>
<wsHttpBinding>
<binding name="MySecureBinding">
<security mode ="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="false"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
Due to the value of false, the specified config would mandate that the WCF clients need to obtain the service credential (in this case, an X.509 certificate) out of band. Out of band in this situation means that the client needs to have a service side certificate in one of its certificate stores.
If one would put negotiateServiceCredential="true" in the upper configuration file this would not be necessary. Indigo would start with a SPNego protocol to exchange the service credentials using startup messages. For the client side, this is good in certain situations, where you would not want to (or were unable to) store service side credentials on the client. The major drawback is that this forces you to use SPNego during initialization phase and it forces you to do it every time you start up the client.
If the clientCredentialType attribute equals to Anonymous, Username, or Certificate, setting this attribute to false implies that the client needs to define the serviceCertificate attribute. The following would be a valid config value for having clientCrendentialType="Certificate" (again, limiting it to only the behavior element:
<behavior name="MyBehavior">
<serviceCredentials>
<serviceCertificate
x509FindType="FindBySubjectName"
findValue="<My Certificate Subject>"
storeLocation="LocalMachine"
storeName="My"/>
</serviceCredentials>
</behavior>
As a reminder, the default value of negotiateServiceCredential attribute is true.
To put all this into perspective, this is a possible WCF config file:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="MySecureBinding">
<security mode ="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="false"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<behavior name="MyBehavior">
<serviceCredentials>
<serviceCertificate
x509FindType="FindBySubjectName"
findValue="MyCertSubject"
storeLocation="LocalMachine"
storeName="My"/>
</serviceCredentials>
</behavior>
<services>
<service name="MyService" behaviorConfiguration="MyBehavior">
<endpoint address="" binding="wsHttpBinding"
bindingConfiguration="MySecureBinding" contract="MyNamespace.MyContract"/>
</service>
</services>
</system.serviceModel>
This config file mandates that the client has service credentials available out of band. Specifically it should be available in the local machine certificate store. The certificate should have a substring of MyCertSubject inside its subject. If this is not the case, one would not be able to call the service successfully.