Obviously you're going to rebuild compromised servers and change all the keys... as soon as you find out you've been hacked.
What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.
You're going to have to re-key because as soon as you got hacked the security of your SSO scheme is likely nil. When you find out about has nothing to do with anything.
In any case, no part of block cipher crypto requires every pair of participants to share the same key --- even in the unlikely even that you needed all-pairs keys (virtually all SSO systems have a star topology).
The idea that a system is going to resist forgery because it uses public key cryptography would be amusing if it wasn't so common. In reality, cryptography does not work the way _Applied Cryptography_ says it does; it works more like the way _Cryptography Engineering_ says it does. In other words: it conspires at all points and at all times to fuck you.
I take it you're being sarcastic, but the negative comments you're receiving are I think because you departed from giving advice on implementation and strategy, and attempted to give a piece of cryptographic advice.
The only way anyone gets to imply that public key crypto is less secure, or more dangerous, without being challenged, is if a new attack is presented. Otherwise it's all innuendo and handwaving.
Most apps and sites may not derive any advantage from public key crypto, but you can't say that for sure until you see a site (or SSO multi-site) design.
What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.