This question was asked at my last event - IP stands for Identity provider and RP stands for Relying party. Do remember that we are talking only about managed (not personal) cards here. Nigel Watling of the CardSpace group was kind enough to provide me with a detailed answer, so here it is....
Establishing trust between an RP and an IP is a business problem as much as a technical one. The RP has to decide which IPs to trust and the IP has to decide whether it is an auditing or non-auditing IP (i.e. whether it mandates receiving the RP’s public key – and therefore its identity – or not). It’s obvious that an RP might only trust data from certain sources but equally an IP (e.g. a bank) might only wish to provide identity for certain recipients (e.g. a bank’s own website but no other sites).
Technically, the RP can specify in policy which issuer to trust so a particular card is highlighted to the user. However, the real work comes with token validation. When the RP receives a security token (from an IP) it must always check the validity of the token, including the signature and public key. When a business relationship is in place the IP’s public key will correspond to a known, stored value. In other words, when an RP decides to trust a particular IP it stores that IP’s public key and does a key lookup as part of the token validation. For example, if Dell has a trust relationship with Microsoft it would use Microsoft’s public key to check the validity of the token and where it came from (Microsoft) and hence determine that you were a Microsoft employee and eligible for an employee purchase discount. ADFSv2 provides a UI for doing precisely this kind of trust management. If the RP no longer trusts an IP it simply removes that key.
As for an RP not trusting particular information from an IP while trusting others I’m not quite sure when that makes sense as a scenario but the RP would have code that identifies the IP from its public key+signature and code that identifies a particular user (via the PPID).
Remember the card is just an artifact for issuing and receiving security tokens. Ordinarily, cards do not leave the user’s machine.