1. OpenID RP Reputation in Trusted Exchange NRI 2008/06/10

2. Trusted Exchange (in a Nutshell)

3. Trusted Exchange (Sequences) 1.A User submits a user Identifier (OpenID) to a RP 2.The RP resolves the OP’s location with the OpenID 3.Association process begins between the OP and the RP 4.The RP requests authentication to the OP with openid.tx.policy_url, openid.realm, and optionally AX data request. 5.The OP makes a reputation request for the RP with openid.realm to a RS 6.The OP gets reputation score and a public key of the RP from the RS for the realm. 7.The OP requests the RP a policy that includes Contract proposal incl. what data, purpose, expiry, etc. 8.The RP return the signed proposed policy. 9.The OP checks the signature with the public key obtained from the RS. 10.The OP prompts the user agent whether to accept the policy with the reputation score and the criteria etc. for the users consideration. 11.The User responds with Yes or No. If Yes, it will be signed. 12.The OP returns a authentication response with openid.tx.contract_handle (and ax data if there were any.) 13.The RP requests the data with the contract_handle. 14.The OP (in this example... could be other attribute authorities) returns data (which includes contract handle and signed by the authority) encrypted with the session key which is encrypted by the public key and sent with the data.

4. RP Reputation in TX (Actors) 1.OP(OpenID Provider): OP requests a reputation score of RP that OP authenticates for. 2.RP(Relying Party): RP belongs to a realm that is organaized by RS. RP must register to a realm with its public key in order to be discovered by OP at user authentication. 3.RS/RA(Reputation Service or Reputation Authority): RS manages RP’s reputation information in a context of a realm and its public keys for link contract processes that later occur. It also provides a reputation score to OP based upon OP’s request.

5. RP Reputation in TX (Sequences) 1.There is a realm that defines a domain of a Reputation context managed by a Reputation Authority or Service such as a Financial Institute Reputation Service. Information about a realm(a reputation service provider) contains URLs for the service discovery used by OPs. 2.RPs must pre-register to join a realm with its public keys such as a RSA key or a X509 certificate. 3.When RP requests user authentication to OP, pass openid.realm parameter to OP. 4.OP resolves Reputation Service(RS) in the realm where RP belongs with a url in openid.realm. 5.OP request RS the reputation score of the RP. 6.RS response the reputation score to OP.

6. Scores calculation model in RS Auditing and Certification This is a time tested method of establishing a reputation for the parties and the services involved. Prime example is the company audit to establish the trustability of the financial statements of the company in question, but others include such things like stock rating, ISO9001, SAS70, Zagat and Michelin rating for restaurants, etc. In a more technical world, web server certificats (e.g. EV Certs) has been there for over a decade. Obvious limitation of this method is that it is only periodically conducted. Thus, it will not be detect eve if the quality of the services may radically dropped between the audit timings. Collective Intelligence is a complimentally method to fill this gap. Collective Intelligence Prime example of the Collective Intelligence are such things like eBay reputation, digg, etc. In a more traditional world, "Word of Mouth" has served such purpose. There can be many methods for doing this. A party that has conducted a transaction with the other party may be eligible for casting a vote for the rating of the party. Also, there can be a reputation aggregator. These are the subject of the interest of the Open Reputation Management Systems TC which is being formed at OASIS Open.