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

Reply via email to