“INTRODUCING “GENEVA�?whitepaper describes situation when user in enterprise X accesses web application in enterprise Y with identity that matches this application’s requirements.

Here clearly said that Geneva CardSpace would traverse this kind of federation relationship:

0. Application determines which IP-STS it trusts.

1. CardSpace learns application token requirements,

2. Contacts STS in enterprise Y to learn his token requirements.

3. Asks user’s home realm STS to issue token to STS in enterprise Y

4. And finally, STS in enterprise Y, after verifying received token, issues token that allows this user to access the application.

The question is:

1) How to configure my web application so that it notice cardspace which IP-STS he trusts.

2) Does Geneva Server beta 2 support these interactions (according to “�?we establish trust-relationship between Geneva Servers in two security realms, but in property window of added IP we have seen no active endpoint, which could receive tokens)?

3) Can Windows CardSpace traverse this kind of federation relationship?

Establishing a naming convention to refer to the various entities involved.
RP -> Web application in enterprise Y
RP-STS -> STS in enterprise Y
IP-STS -> STS in enterprise X

>0. Application determines which IP-STS it trusts.
This is not true. The RP just says that it needs token from RP-STS. RP does not know about the IP-STS.

As for your questions:
1. The RP just gets configured to receive tokens from RP-STS. It does not need to know about the IP-STS. On the RP-STS's login page the object tag doesn't try to explicitly list what IP-STS to trust. The object tag hardly has any parameters set (like claims, issuer, etc). So any information card on the client's machine would "match" and the user has to choose between them.Ideally the user would know what card to use. Geneva Server and CardSpace provide support via "admin policy" through group policy to auto-select (and auto-use) the correct card so that the user does not have to choose the card. More details here: http://blogs.msdn.com/card/archive/2009/06/09/enterprise-policy-for-zero-click-sign-in-using-information-cards.aspx
2. Yes, Geneva server supports this. You can try the hand-on lab. On the IP-STS, look at the configured "relying party" for the RP-STS. The identifiers for the RP-STS will have the symmetric/asymmetric SAML token endpoints for both trust versions.
3. Yes.In above answersI assumed that the CardSpace's object tagis on the RP-STS login page. But it is also possible to put this on the RP page directly. In this case, the object tag must have the parameters:
- issuer=<actual endpoint of an active SAML WS-Trust endpoint>. For eg: https://sts.enterpriseY.com/Trust/13/IssuedTokenMixedAsymmetricBasic256
- issuerPolicy=<The mex address of the RP-STS>. For eg: https://sts.enterpriseY.com/Trust/Mex


-Rakesh

Windows CardSpace Geneva works fine.
But predecessorWindowsCardSpace breakes after retrieving metadata from RP-STS, nevertheless there're no changes were made in configuration of website, or geneva server. We just replaced Geneva Cardspace on Windows Cardspace.Message in eventviewer is about wrong policy.

So, Windows CardSpace doesn't support federation relationship ?

CardSpace in .NET Framework has a restriction of requiring atleast one claim as a "required claim". The RP-STS's issued token endpoint does not specify any claim requirement. This affects CardSpace in .NET Framework which will reject this policy. Note that it supports federation relationships with this requirement.
The RP-STS's issued token endpointdoes not have any claims requirement as:
- The RP-STS can trust multiple IP-STS's (different partners) which could have different claim characteristics.
- The actual information about claims to be used in the token is setup out-of-band when establishing the trust in the Geneva admin MMC (and the client's request has less value).

CardSpace Geneva removes this claim requirement.

Will your STS be internet facing or proxied? In that case, you will have to configure the Geneva Server to use the FQDN.