Launchpad's OAuth implementation predates the RFC; the version 1.0 that we implement is the original "OAuth Core 1.0" from http://oauth.net/core/1.0/. That real 1.0 doesn't include oauth_callback_confirmed; it was added in 1.0a. RFC 5849 defines a second version 1.0 (yes, seriously), which is a variant of 1.0a.
Launchpad hasn't upgraded to OAuth Core 1.0a, as the session fixation attack in the original 1.0 isn't relevant to our implementation. OAuth 1.0 was primarily designed for trusted relationships between web services, but in Launchpad it is used for a relationship between a desktop application or script and Launchpad.
For this reason, Launchpad can't trust a particular consumer, as everyone running an application or script possesses the consumer's secret. Since consumer identities aren't trustworthy, an upgrade to 1.0a just complicates the workflow for no benefit -- the attacker could just pretend to be an honest consumer, send a callback URL that points to themselves, and proceed as normal.
Launchpad's OAuth implementation predates the RFC; the version 1.0 that we implement is the original "OAuth Core 1.0" from http:// oauth.net/ core/1. 0/. That real 1.0 doesn't include oauth_callback_ confirmed; it was added in 1.0a. RFC 5849 defines a second version 1.0 (yes, seriously), which is a variant of 1.0a.
Launchpad hasn't upgraded to OAuth Core 1.0a, as the session fixation attack in the original 1.0 isn't relevant to our implementation. OAuth 1.0 was primarily designed for trusted relationships between web services, but in Launchpad it is used for a relationship between a desktop application or script and Launchpad.
For this reason, Launchpad can't trust a particular consumer, as everyone running an application or script possesses the consumer's secret. Since consumer identities aren't trustworthy, an upgrade to 1.0a just complicates the workflow for no benefit -- the attacker could just pretend to be an honest consumer, send a callback URL that points to themselves, and proceed as normal.