Clearly, this group is making choices based on the kind of applications using OAuth 1.0 today. The decision to focus on bearer tokens came from specific experiences and types of consumer web services.
I'm all for a simple and generic way to issue a token with additional attributes such as a secret, required algorithm, etc. But main objection is to the publication of a standard that promotes bearer token as its "purest" form, and moves something that I consider a core security component to somewhere else. I completely agree that we are going to have more than one signature mechanism. Any attempt to come up with some unified and generically useful method is idiotic. We have very different views, approaches, and needs. However, I'd like us to pick one that is simple and in line with the 1.0 approach - this is very much in line with the market expectation, and the expectations of most people who joined this group to work on the next version of OAuth. My plan from the time I brought OAuth to the IETF and worked to create this working group was to build directly on top of the 1.0 signature method. We don't need to go far, just clean it up a bit to make it simpler and reflect the improve environment OAuth operates in (three years later). IOW, instead of wasting another 6 months of this pointless debate regarding signatures, I would like to see us take the 1.0 HMAC method, have a focused discussion about how it can be made better without changing its architecture (basically, just simplifying the base string), and including that with a clear method for extensions. In addition, I would hope that Dirk's proposal moves forward and reaches a stable state alongside core, so that it too, can be referenced. If we cannot agree on one (and we cannot), I want us to provide options. What I absolutely object to is presenting a specification that to a new reader will read as if bearer tokens are the default way to go. OAuth 2.0 core today reads like a complete protocol and that's my problem. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Sunday, September 26, 2010 6:13 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Basic signature support in the core specification > > -1 to including a signature mechanism in OAuth2 core > > +1 to OAuth2 being clear about how it can deliver a secret key (and algorithm > id etc) that can be used by a signature mechanism > > Firstly -- a mechanism to sign HTTP requests would be great, but should not > be dependent on methods for users to delegate authority to apps, or on > methods for apps to get temporary, less-privileged credentials. That is, don't > make it OAuth-specific. > Defining a request signing mechanism in OAuth2 core will cripple it with > OAuth-specific quirks. The OAuth1 signing mechanism, for instance: uses > names with "oauth_" prefixes; uses 2 keys (an apps long-term key, and the > delegation-specific token key) whereas generic signing mechanisms > invariable work with a single signing key; and overloads a single HTTP > authentication scheme name with multiple purposes (indicating a server > supports delegation, and conveying a request signature). > > Secondly -- there isn't just one sensible signing mechanism, so how do we > pick which one is specified in OAuth2 core. An enveloping-style signature (eg > magic signatures?); an OAuth1-style signature using 2 keys; a signature > covering HTTP method/URI/body but not other headers; a signature covering > any HTTP headers; a signature that can be encoded in a URI; a signature that > also works on non-HTTP systems; a signature scheme that is efficient when > the client app already has its own long-term public/private key pair... > > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
