Comment 4 for bug 1566416

I'm trying to grok the attack vectors here.
 1. User's signing key is compromised (as Guang mentioned, but not really the concern here)
 2. The service using s3_token is compromised and an attacker can see the HTTP transactions between the service and keystone.
 3. The attacker has compromised a different node, but is able to see the traffic between the service and keystone.

Are there any that I am missing?

I don't see how the proposed solution handles any of those cases. The alternative solution is more like what other protocols do and at least limits the timeframe of the abuse. We can also push SSL as a way to prevent #3.

Can you provide more details as to how the attacker gets access to those headers? It would make it much easier to make sure our solution prevents it.