Hi,
I don't have any specific knowledge of how the Live ID SDK is shaping up, but it seems to me that your assumptions are very reasonable. No matter what the SDK does, there has to be a way for it to send some sort of unique token value to your app so that you can associate storage or activities with that user. Whether that's a string, a byte array, or a GUID is really not important, since data is easily converted between those representations.
For security and privacy reasons, you should not assume that the unique token value for a user will be the same in different apps or in different web domains. The user may be using only one LiveID in multiple apps, but applications should never know their actual LiveID, only some form of nonreversible derivative token which is unique to the requesting application and domain. This is to prevent harvesting of user activity patterns across multiple sites or applications.
One app, one user LiveID, one user token.
Different app, same user LiveID, different user token.
Again, I'm not speaking for the LiveID SDK, I'm just stating my opinions based on the constraints of privacy and security in web development.
-Danny
In the Client SDK, you would either use the Identity.UserName or Identity.cId properties to store personalized data for a user. For more information, please see the reference documentation in the SDK, available for download here: