On 2/9/09 2:54 PM, Seth Fitzsimmons wrote: > Hi all. > > 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 > summer.
Yep, it was good to see you yesterday in SF. :) Sorry for the delayed
processing of this email.
> 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.
>
> Here goes.
>
> "findmenow" is mis-spelled in section 2 ("[email protected]")
Fixed.
> 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
> "request token."
> 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
> User.
> 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
> operations.)
Thanks, I cleaned that up using your text, with a few additional tweaks
for clarification.
> Example 1 is missing a "jid" attribute in the <subscribe/> element.
> It should either be "[email protected]/bot" or
> "[email protected]".
Fixed.
> 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.)
My preference as well. Clarified in the spec.
> 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 parameters.
> <unsupported-signature-method/> The specified signature method is not
> supported by the server.
Thanks, that's very helpful.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
