I'm not sure if I am describing something that has already been proposed. If not, I would like to coin this "Signed Double Submit Cookies" as a method to improve the Double Submit Cookies technique that attempts to prevent CSRF attacks.
Here is the concept:
Before outputting a web page, the server sets a cookie in the header where the value includes two values:
token value generated from a strong random number, and
signature value which is the signature of the token (or maybe simply a hash of it that has been salted).
When the client makes subsequent requests, it reads the cookie and includes the token+signature in the POST or GET requests (along with the cookie being automatically in the request headers).
When the server receives the request, it authenticates by:
checking if the token+signature included in the POST or GET requests matches the cookie value in the request header, and
taking the (cookie/query string) token value and signs it again and compares if the resulting signature matches the (cookie/query string) signature value. If matches, it proves that the cookie has not been blindly written by a subdomain or something else.
For the sake of argument, let's assume that XSS attack preventions have been properly implemented and SSL only is true.
Has this method been used before? Does it properly prevent the attack where a subdomain writes cookies to the parent domain?
[EDIT: Originally I had the token and signature in two separate cookies, but to simplify as suggested by @SteffenUllrich, I have edited the question to reflect both the token and signature in one cookie.]