Provide reliable serialization mechanism (not objectstream)

The current way to handle serialization via objectstream may be the solution that was easiest to implement (and fastest at runtime?), but it has some serious disadvantages. The negative effects are also visible in issues like #320 and #200.

I think this is rather unfortunate, because the current approach makes the whole microservice based application potentially a deployment monolith. When you change a class in one service then you also need to change all other services that fetch the underlying data. The current approach is very very fragile :-(

I was first made aware of this problem when I tried to upgrade one service from spring boot 1.2.x to 1.3.x. Due to the fact that spring security changed, the UserDetails implementation changed too and the whole app broke apart. This is really bad, because now I have to do a big bang release of all services that use the session at once.

What I would expect to be possible:
Microservice 1 handles the user authentication, as it does more than just displaying it, it has it's own UserDetails Implementation.
Microservice 2 just uses a simple POJO to read the UserDetails from the session to display it and make security related decisions

This doesn't work at all at the moment, as both services need to use exactly the same implementation.

Wouldn't it be much more robust to use something like json/jsonb or something like that?
Then you even could use non java clients to read the same session info.
#283 seems to allow a better serialization strategy, but every spring-session user has to come up with his own implementation and I think this is a very common use-case and it would be great it spring would ship with a good solution.

The issue names no implementation files or tests. Start by reading the discussions in #283, #320, and #200, then trace the current ObjectStream-based session serialization. Done requires an agreed serialization strategy that lets services use compatible UserDetails representations without sharing the exact implementation.