Jaa

CardSpace question - just how is trust established or revoked between the IP and the RP for managed cards?

  • Artikkeli

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.

Comments

  • Anonymous
    April 10, 2007
    My question is what it will take to gain trust from bank that issues the managed cards and what they will be looking for from you of the sites that you then trust.. Ie i am website..ChucksGoods.com I selling widgets. I can either go to each bank and go through there loops to get trust or i can go to another website abcd.com that has trust from all the banks and get trust from them.   WHat are the guidlines for the abcd.com to get trust from the credit card companies and what are going to be the requirments for chucksgoods.com to get trust from abcd.com..

  • Anonymous
    April 10, 2007
    from above "when an RP (website) decides to trust a particular IP (in your question a bank) it stores that IP’s public key and does a key lookup as part of the token validation" do remember that in the CURRENT iteration of CardSpace, the function of this implementation is to PROVIDE identity and NOT (yet) to provide payment

  • Anonymous
    June 24, 2008
    Separating Logon Authentication Trust from the rest of this would make it much much simpler.  A site can determine which Trusted Authentiation Services (subset of IP functionality) to trust by looking at either their individual token, or at the trusted issuer, just like SSL.  So one might trust authentication services with Verisign tokens for example.