Yep, client, server a set of vectors and a wiki document would be a good start. Would be happy to pitch-in. Cheers <k/>
|-----Original Message----- |From: [email protected] [mailto:[email protected]] On Behalf |Of Hans Granqvist |Sent: Saturday, January 10, 2009 9:29 AM |To: [email protected] |Subject: [oauth] Re: Standardizing the OAuth Client Libraries | | |Very useful blog post, thanks! | | |For me, an OAuth RI has three parts: | |1. Client code (consumer mainly). | |2. Server code (service provider) or a testable live service. | |3. A set of test vectors so that 1. and 2. know a certain |set of input yield a specific set of output. (This is not |trivial when randomness is part of a protocol, btw.) | | |No need for extreme formality to get started. For developers, |any "official best-effort" reference implementation OAuth endpoints |running somewhere would be invaluable. | |http://oauth.net seems a natural place, but it could be anywhere |as long as everyone agrees. | |Any takers? | |Hans | | | |On Jan 8, 2009, at 8:24 PM, Eran Hammer-Lahav wrote: | |> |> BTW, ignoring the fact that it part of it (RSA-SHA1) only works on |> Windows, I consider my signature blog post [1] a reference |> implementation of OAuth written in JS. |> |> EHL |> |> [1] http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html |> |> |> |> On Jan 8, 5:44 pm, John Kristian <[email protected]> wrote: |>> By 'programming interface' I mean an interface between software |>> modules, like between an OAuth library and software that calls it. |>> By |>> 'protocol interface' I mean the bytes transmitted over the network |>> between the consumer and service provider. Think of a layering |>> diagram, in which an OAuth library has a programming interface to |>> higher-level things, and down toward the bottom is a protocol |>> interface. |>> |>> Take percent encoding for example. Neglecting to percent encode |>> leads |>> to a protocol violation, but when you investigate the root cause you |>> might find that the OAuth library provides a correct encoding |>> algorithm but the application neglected to call it. (Users of the |>> Java library have done this.) I would say that's a programming |>> problem: it was caused by erroneous interaction between the |>> application and the library. The protocol violation is merely a |>> consequence. |>> |>> Making the signature base string available for debugging is a fine |>> idea. |>> |>> On Jan 8, 11:35 am, Jesse Clark <[email protected]> wrote: |>> |>>> John, could you expand on what you mean by 'programming interface' |>>> vs. |>>> 'protocol interface' problems? |>> |>>> At ma.gnolia, we spent a pretty decent amount of time helping people |>>> debug rejected signatures that were usually resulting from |>>> differences |>>> in both how the implementor of the client library composed the |>>> Signature Base String and differences in how the various URL |>>> libraries |>>> from different platforms handle encoding. I would call these |>>> 'protocol' issues not software design issues. |>> |>>> However, while trying to debug problems with conflicting signatures, |>>> it was often necessary to ask the client user to try to find the SBS |>>> for a given set of inputs which was not always easy. So, software |>>> design guidelines suggesting a debug mode that would log the SBS |>>> data |>>> somewhere might be a good idea too. |>> |>> |> > | | | --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
