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 -~----------~----~----~----~------~----~------~--~---
