I'm also of the opinion that a protected resource can use the request parameters to differentiate between 1.0 and 2.0.
On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards <rricha...@cdatazone.org>wrote: > On that note are there any guidelines, howtos, etc.. on writing a spec? > I'd recommend focusing on just writing the text and then making it spec like later. Eran has been generally quite willing to take good text and edit it into an actual spec. If you're interested in learning about the spec side of it, you can take a look at http://github.com/daveman692/OAuth-2.0/blob/master/draft-recordon-oauth-v2-ux.xmlwhich is a pretty simple example. --David > -----Original Message----- >>> From: Rob Richards [mailto:rricha...@cdatazone.org] >>> Sent: Friday, July 02, 2010 4:05 AM >>> To: Eran Hammer-Lahav >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Versioning >>> >>> Eran Hammer-Lahav wrote: >>> >>> >>>> [Replying to everything at once...] >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Rob Richards [mailto:rricha...@cdatazone.org] >>>>> Sent: Thursday, July 01, 2010 11:43 AM >>>>> >>>>> >>>>> >>>> >>>> >>>>> Exactly. While it might be needed in the future, there is a need to >>>>> differentiate OAuth 1.0 from 2.0 on resource endpoints right now. >>>>> Outside of requiring an oauth_version parameter (or equivalent) all >>>>> other suggestions leave versioning as a grey area, where things can >>>>> be interpreted one way or another with no consistency. Grey areas in >>>>> >>>>> >>>> specs are a bad thing. >>> >>> >>>> You end up with different languages/libraries dealing with things in >>>>> completely different and incompatible ways because something was not >>>>> clearly spelled out. >>>>> >>>>> >>>>> >>>> This is an area that is clearly on the server side, not the client. >>>> Since the >>>> >>>> >>> core specification leaves discovery out, client developers need to know >>> what >>> version of OAuth is supported by the server and use the right one. >>> Without >>> discovery, the client must know ahead of time what to do. With discovery, >>> the client can choose the right protocol. Either way, the client never >>> just >>> sends a 1.0 or 2.0 requests and hopes for the best. >>> >>> >>>> On the server side, the challenge isn't that significant. When not using >>>> a >>>> >>>> >>> header, the server can use multiple methods to differentiate the version >>> used by the client: >>> >>> >>>> 1. Token syntax >>>> 2. Presence of 'oauth_signature_method' >>>> 3. Presence of 'oauth_signature' >>>> 4. Presence of no other 'oauth_' parameter than 'oauth_token' >>>> >>>> >>>> >>> Never said this was hard just that it needs to be documented. >>> >>> >>>> With this the spec needs to including some wording to explicitly >>>>> define how to handle the case when running an endpoint supporting >>>>> both OAuth >>>>> 1.0 and 2.0 and the oauth2_token is missing then the call is handled >>>>> according to the OAuth 1.0/a spec. Whatever is decided, be it a >>>>> version parameter, the use of oauth2_token or the check for the >>>>> existence of the oauth_signature_method parameter, etc///, the spec >>>>> needs to define and be explicit on how a resource endpoint determines >>>>> between a 1.0 and 2.0 call when both are supported. >>>>> >>>>> >>>>> >>>> The damage done by interpreting a malformed 1.0 request (the odd >>>> >>>> >>> attempt to use 1.0 by only including 'oauth_token') is at most returning >>> an >>> 'invalid-token' response. I hope every server developer understands that >>> they should not share tokens between 1.0 and 2.0 with completely >>> different >>> security properties. >>> Still the issue that different error codes returned which a client may >>> handle >>> differently. >>> >>> >>>> I think there are more issue with regard to 1.0 to 2.0 migration that >>>> should >>>> >>>> >>> be addressed, and I have asked those who care about this to propose a >>> draft. >>> Given that such a draft will not be useful for a long time, given that >>> the vast >>> majority of OAuth implementation 1-2 years from now will be 2.0, I do not >>> want to include it in the core specification. >>> >>> >>>> In order for your argument to stand, you need to show how the current >>>> >>>> >>> setup leads to interoperability problems. Given the 4 options above, and >>> the >>> fact that a malformed 1.0 request will still fail, I do not agree that >>> interop is >>> affected. >>> >>> >>>> >>>> >>>> >>> OAuth is a service that my company provides to other companies and we >>> will >>> need to run both versions in parallel for many of the customers. >>> There are other companies out there who provide similar service, so this >>> isn't >>> just an isolated problem. We may be transitioning customers to/from our >>> service and the behaviors of the systems need to be the same pre and post >>> migration. >>> There is also the WTF factor for developers. If I make calls to 2 >>> providers (1.0 >>> client), each of which is missing the oauth_signature, I would expect the >>> same response back. An error that its missing a required signature. If >>> one of >>> the providers interprets a missing signature as meaning the call is a 2.0 >>> based >>> call then it will return back a different error code. >>> >>> I would expect that if I implemented 2 independent systems based on a >>> spec >>> they would operate and behave the exact same way, otherwise you can just >>> throw the spec in the pile with the rest of them that have ambiguous >>> sections left to interpretation and cause for argument over who >>> implemented what correctly in their system. >>> >>> Rob >>> >>> >> >> >> > > _______________________________________________ > 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
