So say Alice wants to do some transaction with Bob. Bob and Alice both have RSA keys of a decent length.
Before the transaction takes place, Alice gives Bob a piece of JSON that contains her public key fingerprint, a unique transaction ID, her email address (optional) and a UTC timestamp (Or, for bonus crypto points, the current block number!). Bob signs it with his key, and gives Alice the signature; Alice verifies it. Then Bob does the same to Alice. I'll call this JSON-1 because I am unimaginative.
Then the transaction takes place.
Now, Alice creates and signs a piece of JSON that contains her unique transaction ID, another timestamp, Bob's entire public key, a rating for Bob from -5 to 5, and an optional comment. Bob does the same with Alice's key, transaction ID, and timestamp. This is JSON-2.
Bob and Alice then submit all of the JSON (both the JSON generated before and the JSON generated after the transaction) to a trust server. This can be anything that can host a text file and look it up with a key: a DHT comes to mind.
They are both very happy with the transaction. The next time Bob deals with someone, he sends him both the pieces of JSON Alice signed. The other party can verify it and see that Alice trusts Bob. Then the other party sends Bob's public key to several trust servers, to see if the trust servers have any JSON-1s signed with Bob's key that do not have a matching JSON-2. There are none, in this case, so Bob's rating is whatever Alice gave him.
Alice rated Bob negatively. The next time Bob deals with someone, he doesn't send the JSON about the transactions with Alice, because they'd bring his rating down. But when the other party sends Bob's public key to several trust servers, they come back with Alice's JSON-1, or both JSON-1 and JSON-2. If only the JSON-1 comes back, then Bob gets counted as getting the maximum negative rating. Otherwise, Bob gets the rating in the JSON-2.