...
The idea is intended to reduce the need for state sharing across load balanced CAS instances.
Issues
Approach for other tickets
Ticket granting cookies are not the only tickets CAS vends. CAS also vends service tickets, proxy tickets, proxy granting tickets... When a service validates a service ticket someone presented to it, it will randomly reach one of the load balanced CAS instances. That CAS instance will need to be able to recognize and validate the service ticket. Either this same self-validating-ticket approach would need to be used to encrypt or at least sign the service identifier and other information (renewness) into the service ticket, or the CAS servers would need to share state about outstanding service tickets. Proxy tickets additionally bear an arbitrarily long chain of proxying entities, a chunk of information that would become unweildy for encrypting or signing into the proxy ticket itself.
It's hard to enforce on-time-use and revocation for self-validating tickets. That is, once you validate a service ticket it's not supposed to be re-validatable, to prevent replay attacks.
Potentially large content for ticket granting cookies
The content borne by a ticket granting ticket in CAS 3 is more than merely a String username. The ticket validation response can include arbitrary attributes. All of this content would need to be signed or encrypted into the ticket granting cookie for this self-validating ticket-granting-cookie scheme to work. Which might be fine – presumably a Cookie could accomodate this.
Encrypt or sign?
Signing, rather than encrypting, the information in a ticket granting ticket is probably sufficient. Out of the box, CAS does not authenticate services validating service or proxy tickets, and so the full content of the ticket validation response is available to the possessor of a ticket granting ticket, service ticket, or proxy ticket. Of course, if you were to selectively enhance the ticket validation response on the basis of authenticating services requesting ticket validation, via such means as client certs on those requests, to restrict who has access to what information in a validation response, then the tickets containing this information would need to be encrypted rather than just signed.
Alternatives
An alternative approach is to cluster CAS by sharing state across CAS server instances in a cluster. This shared state could be in an RDBMS or in a messaging, in-memory Java state cache.