Fundamentally modifications to TCP are necessary

I don't think IP conflates these. It just wasn't an issue on the horizon in the design of IP. That said, the original designers of IP did envision that further addressing schemes (e.g the "associative addressing" Cerf & Kahn referred to in their '74 paper) might be layered over TCP.

Sadly, the designers and implementors that followed chose to prioritise short-term performance concerns over the long-term flexibility of IP. It became effectively impossible to insert new protocols between IP and TCP (in the sense of it having an IP protocol number != TCP).

It might still be possible to insert an identity layer. The lower 64 bits of the IPv6 address could be used for this. Unfortunately though:

a) There's no guarantee IPv6 will succeed

b) Even if it does, there are (as usual) short-sighted people out there pushing to abolish the split in IPv6 addresses between network and host ID portions ("Why should we limit the hierarchical network space to 64 bits? Why do we need 64 bits for a host?").

So we shall see if this is possible. Otherwise, it has to be done in TCP.

Identity is a very complex issue. It can mean different things to different people/processes at different times. Think about the identity for an email address, or an SSL cert, or a web page - you can surely think of many different scenarios and distinct issues for each. At the network layer, it is very hard to come up with a universal meaning of identity other than "the location in the network". Identity is an issue that really can't be solved at the network layer, other than equating it with location. Even a shim protocol between TCP and IP can't really say more than "these 2 network locations appear to be controlled by the same entity, around this time".

Anyway... :)