[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Kent Brewster]

Pushed it the other day:

http://developer.netflix.com/walkthrough

The Netflix Authentication Walkthrough will guide you through the
Netflix variation on the OAuth dance, all the way from entering your
developer credentials to actually adding, moving, and deleting a movie
from a user's queue.  Nothing to install on your end; it's all
JavaScript, with some copying and pasting from iframes.

Thanks for the inspiration, Eran; I would not have pushed as hard as I
did to get this done without your call to action.

--Kent

> I know what I'm doing to make OAuth better and easier to use.
>
> What are you?
>
> EHL
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[JR Conlin]

Partly because the authors weren't interested or didn't have the time. 
Partly as a personal exercise to learn new languages. Partly to 
understand the protocol in real, practical terms, and partly because 
like you, I believe it's better to just shut up and do something rather 
than whine or bitch at others to do it. I'd love to get some help, but 
I'm not fretting if I don't.

To address Hans' question, my goal is to provide a reasonably common 
library that folks can give the same sort of inputs and get the same 
sort of outputs. I'm focusing on client only services since that's going 
to be the larger audience. Programmers (like Kent) don't care what the 
minutia of OAuth is. They just want to get to people's address books, 
movie listings, or whatever crap OAuth grants them access to with the 
least amount of hassle.

The libraries all take the same set of arguments (in a few different 
ways based on what folks are most comfortable using).

The libraries all return (as much as they can) a hash of:

the fully signed and qualified GET URL (pop it into your web call of 
choice and it should just work)
the Header arguments (if you prefer using those instead).
the signature value (if that's all you wanted)
and an array of escaped parameters (should you want to construct the 
POST or other fetch)

Right now, it's limited to just HMAC-SHA1, but again, that's what most 
services are using. I can add in RSA or other encryption easily enough.

A lot of the other libraries are very good, if possibly providing more 
than most folks need or want. I'm currently working on the .Net library 
since that's where folks that are using our services are having the most 
amount of problems with. I'm building this stuff in my 'off hours' which 
means that I don't always have 40 hours a week to devote to it, and I 
may go days without doing something. Since there's no pressing demand, 
I'm not particularly worried about getting these out quickly.

Eran Hammer-Lahav wrote:
> Why alone? Did you try to partner with more people and no one was interested?
>
> EHL
>
>   
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of JR Conlin
>> Sent: Wednesday, April 29, 2009 8:41 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: True OAuth Confessions, or Why My Hand-Rolled
>> Calls All Blew Chunks
>>
>>
>> Eran Hammer-Lahav wrote:
>> 
>>> This is my favorite thread theme to bark at.
>>>
>>>   
>>> 3. Libraries are Shit
>>>
>>> Some are. How about write a new one or fix an existing one? How about
>>> just ask the developer for help? People always bring up the idea of a
>>> uniform interface across libraries which is a great idea, but no one
>>> actually put any effort into this.
>>>   
>> Actually, I am trying to do something about this, so you're wrong about
>> "no one". Trying to figure out the various nuances of languages I've
>> not
>> programmed in before is a bit of a trick so it's taking me longer to
>> build them than I'd prefer.
>>
>>
>>
>> 
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Mike Migurski]

> Maybe uniform interfaces across libraries are not necessary a good idea.

In general, OAuth should "dissappear" into libraries just like basic auth; 
it's what I aimed for with my PHP HTTP_Request_OAuth class that adds a 
small amount OAuth to the existing PEAR HTTP_Request package. The idea of 
an authentication standard colonizing the HTTP libraries of various 
languages seems to me like a potential impediment to adoption.

(This is an old version from like year, I never really published it: 
http://teczno.com/HTTP_Request_Oauth.phps)

-mike.

-
michal migurski- m...@stamen.com
  415.558.1610



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Hans Granqvist]

Maybe uniform interfaces across libraries are not necessary a good idea.

Does it make sense to have imperative interfaces in functional
languages or vice versa?

Good APIs are be germane and to the target language. Java Collections,
a wonderful set of
APIs as it is, doesn't make more sense in Lisp than car and cdr does in Java.

I think to some level this if we narrow to "more standard" languages
like Java, Python,
Perl, etc... They all have their peculiar feel and a uniform interface
across libraries may be one
of those solutions that never feel quite right.

Just a thought
Hans

PS. I think libraries today are pretty good... what exactly is missing
that cannot be abstracted
on another level?



On Wed, Apr 29, 2009 at 9:33 PM, Eran Hammer-Lahav  wrote:
>
> Why alone? Did you try to partner with more people and no one was interested?
>
> EHL
>
>> -Original Message-
>> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
>> Of JR Conlin
>> Sent: Wednesday, April 29, 2009 8:41 PM
>> To: oauth@googlegroups.com
>> Subject: [oauth] Re: True OAuth Confessions, or Why My Hand-Rolled
>> Calls All Blew Chunks
>>
>>
>> Eran Hammer-Lahav wrote:
>> > This is my favorite thread theme to bark at.
>> >
>>
>> > 3. Libraries are Shit
>> >
>> > Some are. How about write a new one or fix an existing one? How about
>> > just ask the developer for help? People always bring up the idea of a
>> > uniform interface across libraries which is a great idea, but no one
>> > actually put any effort into this.
>> Actually, I am trying to do something about this, so you're wrong about
>> "no one". Trying to figure out the various nuances of languages I've
>> not
>> programmed in before is a bit of a trick so it's taking me longer to
>> build them than I'd prefer.
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Eran Hammer-Lahav]

Why alone? Did you try to partner with more people and no one was interested?

EHL

> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of JR Conlin
> Sent: Wednesday, April 29, 2009 8:41 PM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: True OAuth Confessions, or Why My Hand-Rolled
> Calls All Blew Chunks
> 
> 
> Eran Hammer-Lahav wrote:
> > This is my favorite thread theme to bark at.
> >
> 
> > 3. Libraries are Shit
> >
> > Some are. How about write a new one or fix an existing one? How about
> > just ask the developer for help? People always bring up the idea of a
> > uniform interface across libraries which is a great idea, but no one
> > actually put any effort into this.
> Actually, I am trying to do something about this, so you're wrong about
> "no one". Trying to figure out the various nuances of languages I've
> not
> programmed in before is a bit of a trick so it's taking me longer to
> build them than I'd prefer.
> 
> 
> 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[JR Conlin]

Eran Hammer-Lahav wrote:
> This is my favorite thread theme to bark at.
>

> 3. Libraries are Shit
>
> Some are. How about write a new one or fix an existing one? How about 
> just ask the developer for help? People always bring up the idea of a 
> uniform interface across libraries which is a great idea, but no one 
> actually put any effort into this.
Actually, I am trying to do something about this, so you're wrong about 
"no one". Trying to figure out the various nuances of languages I've not 
programmed in before is a bit of a trick so it's taking me longer to 
build them than I'd prefer.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Eran Hammer-Lahav]

This is my favorite thread theme to bark at.

That is, people brainstorming ideas on how to make the world a better place 
without actually doing anything. None of this is new and this email is not 
meant for anyone in particular.

---

1. Signature Clusterfuck

The signature workflow is the way it is for a reason. If you want to learn the 
reason, you can ask or you can go back to the discussions about it from the 
first few months of this list. A few months ago I spent a few days coming up 
with this tool which is both a tutorial and debugger:

http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html

It is linked to from:

http://oauth.net/documentation/getting-started

Which is a pretty obvious place to look for help if you are getting started 
with OAuth. No need to read the whole spec to get this figured out.

2. Confusing Specification

Yes, the specification isn't great (editorially speaking). It has many problems 
and is hard to read. This is why I wrote a whole new one:

http://oauth.googlecode.com/svn/spec/core/unofficial/1.0ec/drafts/1/spec.html

Which I think tells a much better story with more examples and steps. I 
received very little feedback on that which is very disappointing. Specs only 
get better with feedback, and if you want to help but don't want to go and 
write guides or libraries, how about read the spec and offer suggestions on 
what can be better and what sections didn't work for you.

3. Libraries are Shit

Some are. How about write a new one or fix an existing one? How about just ask 
the developer for help? People always bring up the idea of a uniform interface 
across libraries which is a great idea, but no one actually put any effort into 
this.

4. But it doesn't do X

Yes, OAuth doesn't cover everything you might need or want. But all you have to 
do is just propose it, add it, spec it, code it. Core 1.0 is a framework. You 
need more? Write an extension and propose it on the list. Get some people 
interested in it. Get code running. Show that it is actually useful beyond your 
own need. I have yet to turn down requests for editorial or marketing help from 
anyone. Don't ask for a new feature, ask for people to give you feedback on how 
you intend to address it!

---

I know what I'm doing to make OAuth better and easier to use.

What are you?

EHL



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Marc Worrell]

On 29 apr 2009, at 18:33, Kent Brewster wrote:
>>  From Kent Brewster's comments I think he didn't read the spec before
>> he started trying to implement OAuth.  He also clearly didn't try out
>> the published test cases.  My impression is that he didn't have a  
>> full
>> understanding of the OAuth protocol before implementing it.
>
> Oh, freely admitted.  I'm a bad, bad developer, more hobbyist than
> professional.  (It pays the rent, though.  :)
>
> Maybe my learning style is broken, but I can't claim to understand
> something before I've successfully implemented it several times, and
> even then all I may really understand are the specific copy-and-paste
> steps I took to make it work.
>
> I don't think I'm alone in this; there have to be developers out there
> who have never touched OAuth and are under terrific pressure to get it
> working right freaking now.  For them it's much less important to know
> how a thing works than it is how to work it.  Does that make sense?

Actually, I don't think your learning style is broken. The "just do  
it" works very well for learning languages, frameworks, swimming and a  
lot of other things.  It is just that with protocols it is useful to  
have a look at the map before you start sailing. :-)

I hope that at some point OAuth will be a defacto standard in all  
frameworks, toolkits and whatnots.  That will help everyone who  
doesn't have the time/energy for rolling his/her own implementation of  
OAuth.

- Marc



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[jr conlin]

Kent Brewster wrote:
> I don't think I'm alone in this; there have to be developers out there
> who have never touched OAuth and are under terrific pressure to get it
> working right freaking now.  For them it's much less important to know
> how a thing works than it is how to work it.  Does that make sense?
>
>   
No, you're not alone. It's an argument I tend to make a good deal, but 
generally get dismissed about.

OAuth is a tool. It's part of a solution. As anyone who's ever worked at 
a Sears can tell you, people will use screwdrivers as hammers, chisels 
and pry bars even though that's not what the tool was originally 
designed to do. If your tool isn't simple enough for them to use and 
doesn't provide what they'd expect, they'll move on to a different tool.

OAuth isn't the only solution out there. There are others. The value of 
those other tools can be argued ad much as the value of OAuth can be. 
Demanding additional effort for seemingly minor return simply makes 
those other tools more attractive.

Consider it this way, there are lots of ways of making the Betamax far 
better, but does it really matter?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Kent Brewster]

On Apr 28, 1:10 am, Marc Worrell  wrote:

> From Kent Brewster's comments I think he didn't read the spec before  
> he started trying to implement OAuth.  He also clearly didn't try out  
> the published test cases.  My impression is that he didn't have a full  
> understanding of the OAuth protocol before implementing it.

Oh, freely admitted.  I'm a bad, bad developer, more hobbyist than
professional.  (It pays the rent, though.  :)

Maybe my learning style is broken, but I can't claim to understand
something before I've successfully implemented it several times, and
even then all I may really understand are the specific copy-and-paste
steps I took to make it work.

I don't think I'm alone in this; there have to be developers out there
who have never touched OAuth and are under terrific pressure to get it
working right freaking now.  For them it's much less important to know
how a thing works than it is how to work it.  Does that make sense?

--Kent

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Manish Pandit]

On Apr 28, 1:37 pm, Jonathan Sergent  wrote:
> I can't help but think that if our libraries were good enough, people
> wouldn't run into these problems in the first place.  Maybe I'm too
> optimistic, but I would hope that most people using OAuth never have to
> implement the parameter encoding themselves.
>
> There were really specific reasons we did the parameter encoding the way we
> did...

I'd say a complete stack of test cases with coverage should help folks
gain more confidence in sections 5 and 9, which I think seem to be the
hardest ones. I like http://oauth.pbworks.com/TestCases but it could
be evolved more (I'd look into items that I can add there). Overall I
found the beginner's guide and the editor's cut of the spec helping me
a lot. Another factor is familiarity with something like OAuth (like
experience with writing Flickr/Facebook apps using their non-OAuth
API) also helps to hit the ground running, as the core concept is more
or less the same albeit non-standard. From my experience I'd say that
the spec is hard, OAuth as a concept is not, and if a broader range of
test cases would accompany the documentation, that'd make the consumer
+provider implementors' lives a lot easier.

-cheers,
Manish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[jr conlin]

Agreed.

Granted, I'm starting to think that there ought to be a specification 
for how the libraries are put together, but that's probably beside the 
point. I will note that from the library point of view, you really want 
to minimize the amount of thought that your end user has to give in 
order to use your stuff. Case in point: .Net has the nasty habit of 
returning lower case hex values in the encoded results. If your library 
doesn't return a fully formed result (and instead just returns a 
calculated signature string), you're rolling out the red carpet of 
frustration for whoever picks up your library and tries to use it since 
they now have to replicate how the SBS was generated to give your 
signature.

There are definite, valid reasons for why OAuth is built the way it is. 
It's also really easy for folks here to get lost in the details of OAuth 
and forget that it's just a tiny part of a much larger set of issues for 
whatever developer wants to use it to solve a problem. For folks out 
there building apps and services: Easy trumps detailed.


Jonathan Sergent wrote:
> I can't help but think that if our libraries were good enough, people 
> wouldn't run into these problems in the first place.  Maybe I'm too 
> optimistic, but I would hope that most people using OAuth never have 
> to implement the parameter encoding themselves.
>
> There were really specific reasons we did the parameter encoding the 
> way we did...
>
> On Tue, Apr 28, 2009 at 12:15 PM, John Panzer  > wrote:
>
> IIRC, I believe the signing is a workaround for environments that
> can't or don't want to support SSL.  And SSL is problematic
> primarily for small SPs that can't justify purchase of their own
> certs.  Unfortunately, this puts a burden on clients.
>
> Also, most of these come down to encoding issues, which are just
> always tricky IMHO.  Either you end up breaking immediately
> (because your signature doesn't match) or breaking in edge/subtle
> cases (because your data mostly matches, except when some idiot
> sticks an ampersand in the middle of that one string...).  Not
> sure which is worse in the long term, though obviously the
> break-immediately-with-no-feedback paradigm feels much more
> frustrating.
>
> Perhaps any interop tester service should have a 'forgiving' mode
> that just logs signature validation failures (but lets the code
> proceed), but also displays very explicitly what it thought the
> signature base string was and what it calculated. 
> feedvalidator.org  does something
> similar for RSS and Atom feeds, and it's a fantastic resource for
> experimenting and fixing things.  OAuth is more complicated than
> feeds but it didn't have even that level of testing support.
>
> -John
>
>
> On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist
> mailto:h...@granqvist.com>> wrote:
>
>
> OAuth is complex. Witness last weeks crazy rush to fix
> something that
> was visible
> in the protocol all along. But no one saw it ... most likely
> because
> of protocol complexity.
>
> Seeing as Kent's confessions are mostly around signature: it's odd
> that an authorization
> protocol needs to specify signature mechanisms ... at all.
>
> The end result of an OAuth protocol flow is:
> * some state on the provider, and
> * some manifestation of this state on the consumer, who uses
> this to
> authenticate
> the provider when accessing the resource.
>
> An authz protocol should encompass how to clearly describe
> resources,
> operations,
> and parties authorized. To do that you really need no other
> info than URLs and
> operations.
>
> There is no need to bounce this information via the consumer:
> * The consumer performs an operation on a resource, and
> * The provider checks to see whether the consumer is allowed.
>
> The manner in which the provider authenticates the consumer
> should be completely
> independent from the authorization protocol. Forcing any style of
> authentication is
> a bit draconian. (A token is tied to a secret for authentication)
>
> There are also other issues with baking this all into one
> protocol.
> For example, only
> the provider has to be the one issuing and consuming tokens. This
> format is opaque.
> This means I cannot issue my own authorizations -- ahead of
> time if I
> wants -- nor
> can I move them around providers...
>
> For some reason OAuth came out as a bit of a REST
> anti-pattern. Access
> to resources
> now are shrouded inside an odd mix of additional protocol
> flows and
> signature mechanisms.

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Jonathan Sergent]

I can't help but think that if our libraries were good enough, people
wouldn't run into these problems in the first place.  Maybe I'm too
optimistic, but I would hope that most people using OAuth never have to
implement the parameter encoding themselves.

There were really specific reasons we did the parameter encoding the way we
did...

On Tue, Apr 28, 2009 at 12:15 PM, John Panzer  wrote:

> IIRC, I believe the signing is a workaround for environments that can't or
> don't want to support SSL.  And SSL is problematic primarily for small SPs
> that can't justify purchase of their own certs.  Unfortunately, this puts a
> burden on clients.
>
> Also, most of these come down to encoding issues, which are just always
> tricky IMHO.  Either you end up breaking immediately (because your signature
> doesn't match) or breaking in edge/subtle cases (because your data mostly
> matches, except when some idiot sticks an ampersand in the middle of that
> one string...).  Not sure which is worse in the long term, though obviously
> the break-immediately-with-no-feedback paradigm feels much more frustrating.
>
> Perhaps any interop tester service should have a 'forgiving' mode that just
> logs signature validation failures (but lets the code proceed), but also
> displays very explicitly what it thought the signature base string was and
> what it calculated.  feedvalidator.org does something similar for RSS and
> Atom feeds, and it's a fantastic resource for experimenting and fixing
> things.  OAuth is more complicated than feeds but it didn't have even that
> level of testing support.
>
> -John
>
>
> On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist wrote:
>
>>
>> OAuth is complex. Witness last weeks crazy rush to fix something that
>> was visible
>> in the protocol all along. But no one saw it ... most likely because
>> of protocol complexity.
>>
>> Seeing as Kent's confessions are mostly around signature: it's odd
>> that an authorization
>> protocol needs to specify signature mechanisms ... at all.
>>
>> The end result of an OAuth protocol flow is:
>> * some state on the provider, and
>> * some manifestation of this state on the consumer, who uses this to
>> authenticate
>> the provider when accessing the resource.
>>
>> An authz protocol should encompass how to clearly describe resources,
>> operations,
>> and parties authorized. To do that you really need no other info than URLs
>> and
>> operations.
>>
>> There is no need to bounce this information via the consumer:
>> * The consumer performs an operation on a resource, and
>> * The provider checks to see whether the consumer is allowed.
>>
>> The manner in which the provider authenticates the consumer should be
>> completely
>> independent from the authorization protocol. Forcing any style of
>> authentication is
>> a bit draconian. (A token is tied to a secret for authentication)
>>
>> There are also other issues with baking this all into one protocol.
>> For example, only
>> the provider has to be the one issuing and consuming tokens. This
>> format is opaque.
>> This means I cannot issue my own authorizations -- ahead of time if I
>> wants -- nor
>> can I move them around providers...
>>
>> For some reason OAuth came out as a bit of a REST anti-pattern. Access
>> to resources
>> now are shrouded inside an odd mix of additional protocol flows and
>> signature mechanisms.
>>
>> With non-easily addressable consumers (like desktop apps) you run into
>> the "turtles all
>> the way down" problem when introducing authentication inside an
>> authorization protocol:
>> you can issue secrets and tokens to an app, or try one of the n-legged
>> approaches, but
>> they fail as you never can be sure who or what you're ultimately
>> authenticating.
>>
>> I'm probably rambling a bit, just some thoughts,
>> Hans
>>
>>
>> On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina 
>> wrote:
>> > Is OAuth this hard for everyone else?
>> > http://kentbrewster.com/oauth-confessions/
>> > *Sniff*.
>> > Chris
>> >
>> >
>> > --
>> > Chris Messina
>> > Open Web Advocate
>> >
>> > factoryjoe.com // diso-project.org // openid.net // vidoop.com
>> > This email is:   [ ] bloggable[X] ask first   [ ] private
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[John Panzer]

IIRC, I believe the signing is a workaround for environments that can't or
don't want to support SSL.  And SSL is problematic primarily for small SPs
that can't justify purchase of their own certs.  Unfortunately, this puts a
burden on clients.

Also, most of these come down to encoding issues, which are just always
tricky IMHO.  Either you end up breaking immediately (because your signature
doesn't match) or breaking in edge/subtle cases (because your data mostly
matches, except when some idiot sticks an ampersand in the middle of that
one string...).  Not sure which is worse in the long term, though obviously
the break-immediately-with-no-feedback paradigm feels much more frustrating.

Perhaps any interop tester service should have a 'forgiving' mode that just
logs signature validation failures (but lets the code proceed), but also
displays very explicitly what it thought the signature base string was and
what it calculated.  feedvalidator.org does something similar for RSS and
Atom feeds, and it's a fantastic resource for experimenting and fixing
things.  OAuth is more complicated than feeds but it didn't have even that
level of testing support.

-John

On Mon, Apr 27, 2009 at 11:12 PM, Hans Granqvist  wrote:

>
> OAuth is complex. Witness last weeks crazy rush to fix something that
> was visible
> in the protocol all along. But no one saw it ... most likely because
> of protocol complexity.
>
> Seeing as Kent's confessions are mostly around signature: it's odd
> that an authorization
> protocol needs to specify signature mechanisms ... at all.
>
> The end result of an OAuth protocol flow is:
> * some state on the provider, and
> * some manifestation of this state on the consumer, who uses this to
> authenticate
> the provider when accessing the resource.
>
> An authz protocol should encompass how to clearly describe resources,
> operations,
> and parties authorized. To do that you really need no other info than URLs
> and
> operations.
>
> There is no need to bounce this information via the consumer:
> * The consumer performs an operation on a resource, and
> * The provider checks to see whether the consumer is allowed.
>
> The manner in which the provider authenticates the consumer should be
> completely
> independent from the authorization protocol. Forcing any style of
> authentication is
> a bit draconian. (A token is tied to a secret for authentication)
>
> There are also other issues with baking this all into one protocol.
> For example, only
> the provider has to be the one issuing and consuming tokens. This
> format is opaque.
> This means I cannot issue my own authorizations -- ahead of time if I
> wants -- nor
> can I move them around providers...
>
> For some reason OAuth came out as a bit of a REST anti-pattern. Access
> to resources
> now are shrouded inside an odd mix of additional protocol flows and
> signature mechanisms.
>
> With non-easily addressable consumers (like desktop apps) you run into
> the "turtles all
> the way down" problem when introducing authentication inside an
> authorization protocol:
> you can issue secrets and tokens to an app, or try one of the n-legged
> approaches, but
> they fail as you never can be sure who or what you're ultimately
> authenticating.
>
> I'm probably rambling a bit, just some thoughts,
> Hans
>
>
> On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina 
> wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
> > *Sniff*.
> > Chris
> >
> >
> > --
> > Chris Messina
> > Open Web Advocate
> >
> > factoryjoe.com // diso-project.org // openid.net // vidoop.com
> > This email is:   [ ] bloggable[X] ask first   [ ] private
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Andrew Badera]

Awesome! Thanks for that.

Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera

Sent from Albany, NY, United States

On Tue, Apr 28, 2009 at 10:56 AM, Peter Keane  wrote:

>
> I can say I would not have gotten very far withoout Google OAuth
> playground:
>
> http://googlecodesamples.com/oauth_playground/
>
> --peter
>
> On Tue, Apr 28, 2009 at 9:39 AM, Gilles Devaux 
> wrote:
> >
> > Agree.
> > OAuth is not that complicated, reading the specs is. But honestly, if
> > you forget to sort the parameters before concatenating it means you
> > haven't read them at all (OAuth 1.0 - 9.1.1).
> >
> > One thing that really helped me to understand the flow was to create a
> > fake Service Provider.
> >
> > --Gilles
> >
> > On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara 
> wrote:
> >>
> >> On 4/28/09 1:42 AM, Chris Messina wrote:
> >>> Is OAuth this hard for everyone else?
> >>>
> >>> http://kentbrewster.com/oauth-confessions/
> >>>
> >>> *Sniff*.
> >>
> >> Funny enough, I ran into at least a few of the items on his list when
> >> writing my own OAuth consumer implementation from scratch.
> >>
> >> I honestly think that the OAuth _design_ isn't what makes it difficult.
> >>  It's the way the specification is written.  What really bit me in the
> >> ass the hardest was the "Parameter Encoding" requirement of the
> >> signature when using HTTP header authentication.  Deviating from the RFC
> >> just for OAuth violates POLS, guys.
> >>
> >> Honestly, after trying to decipher the spec. and not getting very far, I
> >> put it aside and went to Eran's GUI:
> >>
> >> http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
> >>
> >> I almost wish I'd not bothered to confuse myself with the spec. and just
> >> used that one page.  It's a _fantastic_ reference implementation for
> >> anyone developing their own OAuth consumer.
> >>
> >> --
> >> Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
> >> Panoptic Computer Network   | http://panoptic.com/
> >>   "He realized the fastest way to change is to laugh at your own
> >> folly -- then you can let go and quickly move on." (p. 70)
> >>
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Peter Keane]

I can say I would not have gotten very far withoout Google OAuth playground:

http://googlecodesamples.com/oauth_playground/

--peter

On Tue, Apr 28, 2009 at 9:39 AM, Gilles Devaux  wrote:
>
> Agree.
> OAuth is not that complicated, reading the specs is. But honestly, if
> you forget to sort the parameters before concatenating it means you
> haven't read them at all (OAuth 1.0 - 9.1.1).
>
> One thing that really helped me to understand the flow was to create a
> fake Service Provider.
>
> --Gilles
>
> On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara  wrote:
>>
>> On 4/28/09 1:42 AM, Chris Messina wrote:
>>> Is OAuth this hard for everyone else?
>>>
>>> http://kentbrewster.com/oauth-confessions/
>>>
>>> *Sniff*.
>>
>> Funny enough, I ran into at least a few of the items on his list when
>> writing my own OAuth consumer implementation from scratch.
>>
>> I honestly think that the OAuth _design_ isn't what makes it difficult.
>>  It's the way the specification is written.  What really bit me in the
>> ass the hardest was the "Parameter Encoding" requirement of the
>> signature when using HTTP header authentication.  Deviating from the RFC
>> just for OAuth violates POLS, guys.
>>
>> Honestly, after trying to decipher the spec. and not getting very far, I
>> put it aside and went to Eran's GUI:
>>
>>     http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
>>
>> I almost wish I'd not bothered to confuse myself with the spec. and just
>> used that one page.  It's a _fantastic_ reference implementation for
>> anyone developing their own OAuth consumer.
>>
>> --
>> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
>> Panoptic Computer Network   | http://panoptic.com/
>>   "He realized the fastest way to change is to laugh at your own
>>     folly -- then you can let go and quickly move on." (p. 70)
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Gilles Devaux]

Agree.
OAuth is not that complicated, reading the specs is. But honestly, if
you forget to sort the parameters before concatenating it means you
haven't read them at all (OAuth 1.0 - 9.1.1).

One thing that really helped me to understand the flow was to create a
fake Service Provider.

--Gilles

On Tue, Apr 28, 2009 at 5:26 AM, Dossy Shiobara  wrote:
>
> On 4/28/09 1:42 AM, Chris Messina wrote:
>> Is OAuth this hard for everyone else?
>>
>> http://kentbrewster.com/oauth-confessions/
>>
>> *Sniff*.
>
> Funny enough, I ran into at least a few of the items on his list when
> writing my own OAuth consumer implementation from scratch.
>
> I honestly think that the OAuth _design_ isn't what makes it difficult.
>  It's the way the specification is written.  What really bit me in the
> ass the hardest was the "Parameter Encoding" requirement of the
> signature when using HTTP header authentication.  Deviating from the RFC
> just for OAuth violates POLS, guys.
>
> Honestly, after trying to decipher the spec. and not getting very far, I
> put it aside and went to Eran's GUI:
>
>     http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html
>
> I almost wish I'd not bothered to confuse myself with the spec. and just
> used that one page.  It's a _fantastic_ reference implementation for
> anyone developing their own OAuth consumer.
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Dossy Shiobara]

On 4/28/09 1:42 AM, Chris Messina wrote:
> Is OAuth this hard for everyone else?
>
> http://kentbrewster.com/oauth-confessions/
>
> *Sniff*.

Funny enough, I ran into at least a few of the items on his list when 
writing my own OAuth consumer implementation from scratch.

I honestly think that the OAuth _design_ isn't what makes it difficult. 
  It's the way the specification is written.  What really bit me in the 
ass the hardest was the "Parameter Encoding" requirement of the 
signature when using HTTP header authentication.  Deviating from the RFC 
just for OAuth violates POLS, guys.

Honestly, after trying to decipher the spec. and not getting very far, I 
put it aside and went to Eran's GUI:

 http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html

I almost wish I'd not bothered to confuse myself with the spec. and just 
used that one page.  It's a _fantastic_ reference implementation for 
anyone developing their own OAuth consumer.

-- 
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
   "He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on." (p. 70)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Paul Lindner]

It wasn't quite that bad..  However I did have a terrible time moving  
OAuth code to production that stumped me for a month.  It turned out  
that the SSL and Host were getting set to the local cluster host  
instead of the load balance external endpoint.

On my second attempt I had OAuth problem reporting working and that  
helped a lot, I was able to see that the URL being used for signature  
calculation was not being set correctly.



On Apr 27, 2009, at 10:42 PM, Chris Messina wrote:

> Is OAuth this hard for everyone else?
>
> http://kentbrewster.com/oauth-confessions/
>
> *Sniff*.
>
> Chris
>
>
> -- 
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Marc Worrell]

Hi Chris,

Luca's list is good.  Maybe you can add a section how someone could  
start implementing OAuth in his software.  And start the section with  
a small list like Luca's.

Maybe you can add a warning about the problems with url encoding in  
different programming languages.  And supply correct versions.

I like to add that whenever you implement a protocol you have to read  
the spec first, or at least a good summary of the spec. The moment you  
understand the protocol (and also the spec) you can start implementing  
it.  Whilst implementing it you add test cases so that you can  
validate your implementation. That is before you start using the  
protocol to talk to an external party.

 From Kent Brewster's comments I think he didn't read the spec before  
he started trying to implement OAuth.  He also clearly didn't try out  
the published test cases.  My impression is that he didn't have a full  
understanding of the OAuth protocol before implementing it.

Programming any protocol, especially security related protocols, is  
careful work. You need to know what you are doing.  You need to grow  
your software by testing.  You need to understand the protocol  
thoroughly.  That is why programmers use libraries for most protocols.

As protocols go, OAuth is not that hard to implement.  Testing it in a  
live situation is hard though, mostly due to the omission of sensible  
error messages.

What could help OAuth is a better standardization of the error message  
returned. Errors like nonce reuse can then be easily caught and  
reported.

- Marc


On 28 apr 2009, at 09:20, Chris Messina wrote:

> Thanks Luca,
>
> Let me ask this: what else could we be doing to make the "walk up"  
> experience of OAuth easier/better?
>
> I think that the website needs an overhaul (as do most of the Open/ 
> Social Stack sites!!). I'd like to know what we could do to make  
> these sites better — meeting a wider community of practice's needs.
>
> Chris
>
> On Tue, Apr 28, 2009 at 12:13 AM, Luca Mearelli  > wrote:
>
> On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina  > wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
>
> I think that we agree that OAuth *is* complex, and has a few hard
> points (specially about the signing process e.g. the signature base
> string composition) but if we think at what it's trying to do (passing
> authorization around in a three subjects dance across untrusted
> channels) that's understandable.
> These are the things that have helped me (might be banal, might be  
> not...):
>
> - read the spec, try to understand the steps,
> - look at the examples and walkthroughs (specially those at  
> hueniverse.com )
> - look at the examples from the library of your choice (the ruby one  
> in my case)
> - try out with the test providers
> - read the mailing list
>
> Luca
>
>
>
>
>
> -- 
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable[X] ask first   [ ] private
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Luca Mearelli]

On Tue, Apr 28, 2009 at 9:20 AM, Chris Messina  wrote:
> Thanks Luca,
> Let me ask this: what else could we be doing to make the "walk up"
> experience of OAuth easier/better?

I'd start from the action points here:
http://josephsmarr.com/2009/02/17/implementing-oauth-is-still-too-hard-but-it-doesnt-have-to-be/
And It'd be great to see (on OAuth.net) an "illustrated OAuth" spec (I
found this http://bit.ly/2j5qT very helpful in understanding the OAuth
attack)

Luca

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Chris Messina]

Thanks Luca,
Let me ask this: what else could we be doing to make the "walk up"
experience of OAuth easier/better?

I think that the website needs an overhaul (as do most of the Open/Social
Stack sites!!). I'd like to know what we could do to make these sites better
— meeting a wider community of practice's needs.

Chris

On Tue, Apr 28, 2009 at 12:13 AM, Luca Mearelli wrote:

>
> On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina 
> wrote:
> > Is OAuth this hard for everyone else?
> > http://kentbrewster.com/oauth-confessions/
>
> I think that we agree that OAuth *is* complex, and has a few hard
> points (specially about the signing process e.g. the signature base
> string composition) but if we think at what it's trying to do (passing
> authorization around in a three subjects dance across untrusted
> channels) that's understandable.
> These are the things that have helped me (might be banal, might be not...):
>
> - read the spec, try to understand the steps,
> - look at the examples and walkthroughs (specially those at hueniverse.com)
> - look at the examples from the library of your choice (the ruby one in my
> case)
> - try out with the test providers
> - read the mailing list
>
> Luca
>
> >
>


-- 
Chris Messina
Open Web Advocate

factoryjoe.com // diso-project.org // openid.net // vidoop.com
This email is:   [ ] bloggable[X] ask first   [ ] private

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Luca Mearelli]

On Tue, Apr 28, 2009 at 7:42 AM, Chris Messina  wrote:
> Is OAuth this hard for everyone else?
> http://kentbrewster.com/oauth-confessions/

I think that we agree that OAuth *is* complex, and has a few hard
points (specially about the signing process e.g. the signature base
string composition) but if we think at what it's trying to do (passing
authorization around in a three subjects dance across untrusted
channels) that's understandable.
These are the things that have helped me (might be banal, might be not...):

- read the spec, try to understand the steps,
- look at the examples and walkthroughs (specially those at hueniverse.com )
- look at the examples from the library of your choice (the ruby one in my case)
- try out with the test providers
- read the mailing list

Luca

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---

[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks

[Hans Granqvist]

OAuth is complex. Witness last weeks crazy rush to fix something that
was visible
in the protocol all along. But no one saw it ... most likely because
of protocol complexity.

Seeing as Kent's confessions are mostly around signature: it's odd
that an authorization
protocol needs to specify signature mechanisms ... at all.

The end result of an OAuth protocol flow is:
* some state on the provider, and
* some manifestation of this state on the consumer, who uses this to
authenticate
the provider when accessing the resource.

An authz protocol should encompass how to clearly describe resources,
operations,
and parties authorized. To do that you really need no other info than URLs and
operations.

There is no need to bounce this information via the consumer:
* The consumer performs an operation on a resource, and
* The provider checks to see whether the consumer is allowed.

The manner in which the provider authenticates the consumer should be completely
independent from the authorization protocol. Forcing any style of
authentication is
a bit draconian. (A token is tied to a secret for authentication)

There are also other issues with baking this all into one protocol.
For example, only
the provider has to be the one issuing and consuming tokens. This
format is opaque.
This means I cannot issue my own authorizations -- ahead of time if I
wants -- nor
can I move them around providers...

For some reason OAuth came out as a bit of a REST anti-pattern. Access
to resources
now are shrouded inside an odd mix of additional protocol flows and
signature mechanisms.

With non-easily addressable consumers (like desktop apps) you run into
the "turtles all
the way down" problem when introducing authentication inside an
authorization protocol:
you can issue secrets and tokens to an app, or try one of the n-legged
approaches, but
they fail as you never can be sure who or what you're ultimately
authenticating.

I'm probably rambling a bit, just some thoughts,
Hans


On Mon, Apr 27, 2009 at 10:42 PM, Chris Messina  wrote:
> Is OAuth this hard for everyone else?
> http://kentbrewster.com/oauth-confessions/
> *Sniff*.
> Chris
>
>
> --
> Chris Messina
> Open Web Advocate
>
> factoryjoe.com // diso-project.org // openid.net // vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---