RP? …. RP Who? …. RP, the good guy, really!

Would you open the door to a stranger? Probably. Would you give up some valuable information to him? Probably not without checking his identity; and of course you won’t take any of his identity, like his business card; you would only honor IDs that were issued by authorities that you trust.

A similar problem exists in Identity Metasystem. The user MUST be in a full control over what data, for what purpose, to whom s/he discloses the identity information (Law #1).

When a user visits a RP’s web service, InfoCard System requires the RP to supply its identity in the form of X509Certificate which is part of Endpoint Reference (EPR)- (for more information about EPR, please see WS-Addressing). Of course, the RP must also prove that it has the possession of the corresponding private key (for example, via signature). The security token submitted to this RP is encrypted using the public key of the certificate. The virus could not just obtain the token, and decrypt the token, since it does not have the RP’s private key.

How does this translate to code/configuration? If you go back to my previous posting, the RP would add the following xml segment in its app.config (system.serviceModel/services/service/endpoint)

<endpoint ...>
  <addressProperties identityType="Dns" identityData="Fabrikam">
    <endpointHeaders>
       <dsig:X509Certificate xmlns:dsig="http://…/xmldsig#">
              MIIDwzCCAqugAwIBAg ...
              ... 4-5 line of base 64 encoding string …
              ...93rQOBW/BjHqg==</dsig:X509Certificate>
   </endpointHeaders>
  </addressProperties>
</endpoint>


The X509Certificate specifies in the service’s endpoint SHOULD contain URL links to the subject and issuer logos. The identity selector (i.e InfoCard) displays these logos prominently when the user must make a trust decision whether to trust the RP and continue the conversation. The logos and the hash of the images are specified in 1.3.6.1.5.5.7.1.12 field in the certificate. The trust decision is recorded in the InfoCard system, so the next time s/he does not have to make the same trust decision again (of course she could revoke her trust to a specific RP).

Of course, the RP identification problem has been solved before with varying degree of success. If users visit to a secured site, they have been educated to look at the locked icon in IE. In InfoCard experience, during the first time visit to RP, the user MUST decide to trust (or not trust) the RP before it can continue the conversation with RP.

 


Next posting, – let’s look at how we could secure the conversation between RP and User.