Note that although the discussion around this issue is in the context of fetching an email from LinkedIn, this is not specifically a LinkedIn problem nor is it necessarily an OAuth 1.0(a) problem. Non-standard parameter flexibility should be available in both OAuth1 and OAuth2 authorization flows.

I've started working on it (can't say I fully understand everything there yet..) but I have couple of questions so far..

• RequestMatchers and ResponseCreators are not pointing to the correct package... (I'm guessing you guys refactored the packages..?)

• Where can I find the jar for MockHttpRequest ? I can't seem to locate it and for now I've just commented out the test. [Replaced it with org.springframework.mock.http.client.MockClientHttpRequest ]

• Additional parameters besides scope - I thought about it for a while and I don't really think we should support that since
  as you mentioned, linkedin did a mix and match with oauth1 and oauth2, but they only support scope parameter and I can't really think of any other provider
  that will support callback parameters or even additional parameters. (besides linkedin which I'm guessing it was too hard for them to support oauth2..)
  So I'm guessing we can simply add a scope param to the ConnectSupport, same like you did in #getOAuth2Parameters. thoughts?

Regarding your first two questions, yes there is some work I need to do to sync up Spring Social with the very latest Spring Test MVC stuff. Originally, Spring Test MVC was a separate project and it underwent a lot of refactoring leading up to its inclusion in Spring Framework 3.2. It seems that the reason my stuff still builds it probably because I have an older spring-test-mvc dependency in my local cache. Put briefly, thanks for pointing that out...I need to address that.

Regarding the third question, I disagree. I would not add an explicit scope parameter to anything that's OAuth 1.0(a) because that parameter is not standard. And even though LinkedIn is the only provider that you know of that has non-standard parameters, it is one data point to illustrate that it could happen. Therefore, it makes more sense to me to generically support some additional parameters that end up on the request as request parameters...it just so happens that "scope" is one we'd set when authorizing for LinkedIn.

As for testings - I've already fixed those issues.

regarding the scope - I've decided to support both for now (unless you think otherwise.. ) . OAuth1Parameters now accept 'scope' parameter same like OAuth2Parameters.
It's working very good, already tried it with Linkedin. as for generic ones, I'm getting some ConcurrentModificationException on the MultiValueMap which I have no idea why.. so I'm still on it.

BTW - to make it work (the new scope param), one has to either create a new Linkedin app or "migrate" it's existing app to support the new API.

https://developer.linkedin.com/documents/member-permissions-migration-guide

http://developer.linkedin.com/forum/when-will-old-apps-have-scope-parameter-enabled

I've made it possible to specify arbitrary parameters when kicking off the authorization flow. Those parameters will be included in the authorization URL and (if OAuth 1.0/a) in the request token URL.

I've also tested this with LinkedIn, setting a "scope" parameter to "r_basicprofile r_emailaddress". When doing so, I was able to fetch the email address from LinkedIn. (Note that I've also added emailAddress to the LinkedInProfileFull class).

You can see an example of how this is used in the Spring Social Showcase example at https://github.com/SpringSource/spring-social-samples/tree/master/spring-social-showcase. I've altered that example to fetch the full LinkedIn profile and to display the user's email address.

Works perfectly, thanks! Regarding your addition of emailAddress to LinkedInProfileFull: when will this be released? Even a milestone or intermediate release would be fine, the last official release for linkedin (1.0.0.RC1) is more than a year old.