There are many ways for a client application to fill out its understanding of an LMS user identity's properties. It is also noteworthy to remember that the D2LWS platform is essentially optimized for service-to-service level operational trust, while the newer Valence platform is optimized for user-to-service operational trust -- this means that all Valence calls must happen in the context of some real, authenticated LMS user account (in the sense that in order to make calls, the client application must first request to acquire a user ID/Key pair for an authenticated user).
If your client service will always be contacted or prompted by the LMS with an LTI launch, then you will have enough capacity from that launch to begin (please see this detailed topic on combining Valence calls with LTI around our Remote Plugin service). There should be a real LMS user that would have initiated that launch somehow, from a logged-in LMS session. Therefore, after the LTI launch, your service can turn right around and make a call to the LMS to request user tokens for the currently auth'd user and this user should almost certainly be the LTI-launching user.
Typically, for services that get contacted from an LTI launch and then want to use Valence, we recommend that you establish a user context immediately after the launch and make a whoami call: this can serve multiple purposes -- it can establish that you have a dependable set of user tokens you can use to make Valence calls on behalf of the launching user, and you can use the information retrieved in the WhoAmIUser data structure to assist in filling out the context of your user identity.
For your particular purposes, the WhoAmIUser data structure contains the first name, last name, unique name (user name), and LMS profile identifier for the launching user, as well as the LMS user identifier (Identifier) property that you can use in the context of other Valence calls should you need to. However, you should also strongly consider a shift to the user-to-service approach: when all the calls take place within the context of a particular user, you may discover that your best route is employing all the "my" routes to fill out the user experience you present to a user -- keep in mind that the user's credentials you employ with your Valence API calls restrict your access to functionality and data exactly as that user would be restricted in the course of his or her normal interactions with the LMS through its web UI.