Yep, you are right. This request could be addressed in a short term by "implementation guidelines" or even an "implementation experience" Wiki/document.
But on a longer term, couple of RIs and a conformance document would be ideal. Again, as you point out, we should address the short term and also work towards medium term deliverables. Cheers <k/> |-----Original Message----- |From: [email protected] [mailto:[email protected]] On Behalf |Of john kemp |Sent: Thursday, January 08, 2009 8:54 AM |To: [email protected] |Subject: [oauth] Re: Standardizing the OAuth Client Libraries | | |On Jan 8, 2009, at 10:04 AM, Krishna Sankar (ksankar) wrote: | |> Which means, we need a conformance spec and a couple of test suits |> implementations. This is all good as it shows that the domain is |> maturing ... Would be happy to help in any way ... | |While I think that a conformance spec. and RI would be very nice for |improving interop, I would guess they would take quite a lot of work |and some agreement among implementations. | |It seemed to me that the original request might be more easily (if |only partially?) satisfied by creating an "implementation guidelines" |document, to which the different library implementers might submit |their "gotchas" and where we could agree "best practices" (not yet |mandatory) such as the ones suggested by JR, and help those who are |implementing their own libraries. | |That could be done by simply creating a wiki page, and adding content. |Such guidelines would be non-binding though, of course. | |- johnk | |> |> Cheers |> <k/> |> |> From: [email protected] [mailto:[email protected]] On |> Behalf Of David Fuelling |> Sent: Thursday, January 08, 2009 6:23 AM |> To: [email protected] |> Subject: [oauth] Re: Standardizing the OAuth Client Libraries |> |> +10. |> On Wed, Jan 7, 2009 at 7:47 PM, jr conlin <[email protected]> wrote: |> |> I know that this list is about OAuth in general, but I'm seeing a |> fairly |> consistent pattern with how people are using the client libraries. |> |> Netflix uses OAuth for all requests. This means that consumers are |> using |> a vast majority of the libraries in order to use our services. Over |> the |> past few months, we've been working with them in order to isolate |> problems and I've been seeing a few issues like .Net's base URL |> encoder |> defaults to lower case hex, Ruby's URL encoder defaults to encoding |> spaces as '+', and others. |> |> While the library authors have done great jobs at working around these |> issues, they haven't always made things easy for their users and have |> expected them to duplicate their efforts to ensure that variables are |> encoded for transfer the same way that they're encoded for the |> signature |> generator. |> |> Users are often frustrated because they call the Library, get the |> OAuth |> Signature Value, yet when they make the call it fails for reasons that |> aren't always obvious. |> |> My proposal is that to get OAuth wider usage, the libraries should be |> built to a common set of guidelines, things like: Hex Values should be |> in upper case, escape routines should be publicly accessible, |> libraries |> should return properly formatted OAuth Authorization Headers, etc. |> Basically, help users avoid making common mistakes which will lead to |> frustration around OAuth. |> |> Thoughts? |> |> |> |> |> > | | | --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
