Well, the "LINQ to Twitter v1.0" is currently sitting in the TwitterExecute.cs class of the linqtowtitter.dll.
There are 2 versions of it, one that is called from the function twitterExecute() and twitterExecute(iTwitterAuthorization).
If we look at the first one that is meant for the usernamePasswordAuthorization, it looks like this:
this.AuthorizedClient = new UsernamePasswordAuthorization();
this.AuthorizedClient.UserAgent = "LINQ To Twitter v1.0";
So, I would assume that the UserAgent is part of the "Auth" section of my first example. My actual concern is that this would open up to less than honest twitter users to be able to 'spoof' clients, as its not actually an authentic client.
The actual goal would be to utilize the ITwitterAuthorization to allow the use of UsernamePasswordAuthentication.
I'm going to have to read thru the API and what needs to be sent to twitter, and maybe read up on this part of the api a bit more.
The authentication in my opinion, would have to be split tho,
step 1 would be to always authenticate the client first, cache the authentication key
step 2. would be to then pass the username/password next.
This would allow for user blocking and client blocking incase someone abused their application, or for identifying 'firehose' clients or corporate users who paid for firehose access.
So... I need to do some reading up and see how you manage the tokens in DesktopOAuth, and see how the twitter api processes the tokens when you pass thru information. Watch for a follow up this weekend.
I think a good place for me to start tho will be to look into the UsernamePasswordAuthentication class and dig into the 'InitializeRequest' and compare how that processes: request.UserAgent = this.UserAgent; and then compare it to
the 'GetVerifier' function of DesktopOAuth, and really see how the whole system works.