>>>>I think MS missed the boat by using the mangled URL as alternative. Having the cookie stored within normal payload data would have been better - even down to allowing new, encrypted non-diskable cookies to be updated via HTTPS:// rest without breaking too much other architecture.
>>>
>>>Yes, this is exactly my point. If it would have been simply added in the query string, I would have been ok with that. At first, this is what I thought it was. Today, when I started to look at this, this is where I realized "Oh, is that really what the URL would look like".
>>
>>It looks like that on your browser (and may be visible in the same way in browser history) - but with https it's encrypted over the wire.
>>In that respect I don't see it as being any less secure than cookies.
>
>true if only one-shot get/post are exchanged. Having cookie-like validation embedded in the payload would make it easier for REST/Ajax/Soap-style enhancements and lessen the pain of rewriting URLs and the ease serverside other stuff mentioned in thumbs down. The URL-mangling smells like premature optimization to me, unless you find some measurements citing massive gains.

No gains really - just a transparent way of handling browsers that don't accept cookies. Embedding info in the payload may be better but harder to implement ?