MEX Ednpoint in CardSpace

By using or implementing of some Security Token Service (according to WS-Trust) it might sound strange
that the MEX endpoint has to be always HTTPS based. However, the fact is that the communication with STS
does not have to be necessarily based on HTTPS. One could ask question:
"Why it is more important to secure the metadata than the data itself"?

For example, following two lines are cut from the INI-file which defines one valid managed card:

. . .
Address=
http://www.fabrikam.com/UserNameToken.svc/usernamepassword/sts
MexAddress=
https://www.fabrikam.com/UserNameToken.svc/usernamepassword/mex
. . .

These lines define the address of the issuer of the managed card and its MEX address.
As you see the first one is based on unsecured HTTP transport and second one on secured
HTTPS transport. In the very first version of CardSpace it was possible to use HTTP for metadata exchange too.
Because the metadata does not contain necessarily sensitive information it is not reasonable to use secured transport
as mandatory one. This is true, but in this case there would be no way for client to authenticate the Security Token Service.
Who can guarantee that retrieved metadata is really retrieved by the service we trust to?
y using of HTTPS the client is able to authenticate the service and avoid something I call "STS-Phishing".

Ok, but one can ask question: "Why the STS endpoint is not required to use secured transport too?"
This can be required, but it doesn't have to be, because messages exchanged with STS can use message security.

Here is the example how to create the right MEX endpoint in WCF, which is compatible with CardSpace:

string mexAddress =
https://www.fabrikam.com/UserNameToken.svc/usernamepassword/mex;
serviceHost.AddServiceEndpoint(ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpsBinding(), mexAddress);

For more information about MEX take a look on specification:
http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf.

http://www.daenet.eu