[Standards] XEP-0235 (OAuth) ambiguities and corrections
seth at mojodna.net
Mon Feb 9 22:54:28 UTC 2009
I hope you're enjoying the Atomium and Sprouts at FOSDEM. Perhaps
I'll see some of you at the IETF BoF in San Francisco or at OSCON this
I've been working on the interop story for XEP-0235. Until last week,
ours (Fire Eagle / switchboard) was the only known client
implementation, so a number of details slipped through the crack.
With the help of a pair of intrepid Java and C# developers, I've
identified some ambiguities and insufficiencies in the spec.
"findmenow" is mis-spelled in section 2 ("travelbot at findemenow.tld")
Here's a proposed re-wording of the order of events to be more in-line
with OAuth terminology:
1. FindMeNow has registered as a consumer application for WorldGPS'
API and has been assigned an OAuth consumer key and secret.
2. WorldGPS maintains a feed for the User's location data in an
XMPP PubSub Node.
3. The User visits FindMeNow.tld and requests real-time updates
from his WorldGPS feed.
4. FindMeNow, over HTTP, requests an OAuth "request token" from
WorldGPS's pubsub service, signing it with FindMeNow's OAuth consumer
key and secret.
5. WorldGPS, if the signature was valid, sends FindMeNow an OAuth
6. FindMeNow then redirects the user to a WorldGPS webpage.
7. On the WorldGPS webpage, the User logs in (or is already logged
in) and is then asked whether to approve of FindMeNow having read-only
access to his geolocation information.
8. The User approves the request and WorldGPS redirects the User
back to FindMeNow.
9. FindMeNow, over HTTP, requests an OAuth "access token", signing
the request with the "request token" that has now been approved by the
10. WorldGPS, if the signature is correct and the request token was
approved, replies with an OAuth "access token".
11. FindMeNow, over XMPP, subscribes to the User's pubsub node using
the OAuth "access token" as described below.
(Steps 1-10 describe OAuth's standard HTTP flow and represent an
out-band means for obtaining OAuth access tokens for use in XMPP
Example 1 is missing a "jid" attribute in the <subscribe/> element.
It should either be "travelbot at findmenow.tld/bot" or
"travelbot at findmenow.tld".
Section 4's anonymous example (should be Example 2?) is missing the
same "jid" attribute. The <oauth_signature> value is also escaped,
conflicting with the example of a calculated signature below. It's
relatively arbitrary as to whether it should be escaped or not, but we
should be consistent. (As PSA notes, XMPP doesn't require such
escaping. Plus, Fire Eagle's extant implementation assumes that
elements are NOT escaped, so that'd be my preference.)
I've heard a couple people wonder what the various OAuth-specific
error messages mean, so I'll take a whack at that:
<duplicated-parameter/> One of the oauth_* elements was provided more than once.
<invalid-consumer-key/> The application's OAuth consumer key is not valid.
<invalid-nonce/> The provided nonce is invalid; it may have already been used.
<invalid-signature/> The provided signature is invalid; confirm that
your signature base string is calculated correctly.
<invalid-token/> The provided access token is invalid; it may have been revoked.
<missing-parameter/> One of the required oauth_* elements is missing.
<token-required/> An access token was not provided.
<unsupported-parameter/> The <oauth> stanza contains unknown or
<unsupported-signature-method/> The specified signature method is not
supported by the server.
On Fri, Feb 6, 2009 at 5:11 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Seth Fitzsimmons wrote:
>> - the XEP (http://xmpp.org/extensions/xep-0235.html
>> <http://xmpp.org/extensions/xep-0235.html>) is ambiguous about
>> whether signatures should be escaped. We've decided to not escape
>> signatures, although we may accept both at some point in the future.
>> I'm planning on following up with standards at xmpp.org
>> <mailto:standards%40xmpp.org> to get this and a few other ambiguities
>> cleared up.
> When I wrote the documentation after OSCON I think I just copied the
> example from the OAuth spec, but that example assumes that the signature
> is included in an HTTP request or in a URL-encoded form, so of course
> the characters are escaped there. In XMPP we don't need to do that kind
> of escaping so I think it is unnecessary. Thus we can have things like this:
> But yes, let's clear that up. :)
More information about the Standards