On Apr 30, 2009, at 12:11 PM, Blaine Cook wrote: > > On Thu, Apr 30, 2009 at 4:50 PM, Eran Hammer-Lahav <[email protected] > > wrote: >>> Really, why not bump the version to 1.1? Is there real magic behind >>> the version number? What's the point of versioning the protocol >>> if revving >>> it is painful? >> >> Because the version has nothing to do with the authorization flow. >> It is about the signature method. We are not changing that. Keep in >> mind that there are plenty of 2-legged clients out there and there >> is no need to break them. > > I agree that we shouldn't break the two legged clients, but disagree > that the version number is only for signatures.
There is a crucial question here - what _does_ the oauth_version parameter indicate? My understanding is that there is an OAuth specification, and that the specification itself has a version. Consumers and SPs which implement a particular version of the specification may indicate which version of the specification to which they adhere by means of the oauth_version parameter. This is essentially just advisory if some parameters involved in the actual protocol flow are present in some versions of the spec. and not others. I would suggest that if we want signature method versioning, then signature method names themselves should be versioned (ie. HMAC_SHA1_v1 or something like that) or a per-method version indicator. I don't think that's a bad idea BTW. But in any case, it should be made clear in the specification what oauth_version is intended to indicate. It should be made more clear in 1.0 what exactly it indicates, for future versions of the specification. > The handling of the > HTTP request flow is very important, and the fact that we need a way > to signify that it has changed underscores that. > > We shouldn't increment the version number in this case (I was and > remain in opposition to pre-determining the versioning approach, since > it doesn't work here, and there's no guarantee that it will continue > to work). How about the following: > > - If the version = 1.0 (or not present) and the oauth_callback > parameter *is* present upon obtaining a request token, then the flow > should be assumed to be Rev. A. I would note that since the 1.0 spec currently says: "Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present." this suggested behaviour (look for oauth_callback in first request to determine which version should be performed) seems not allowed by the 1.0 specification, and a conforming implementation would thus be in violation of the spec. That is, assuming that oauth_version indicates adherence to a particular version of the OAuth specification. I think a reasonable change might be to make an erratum to 1.0 which gives the SP more latitude if the oauth_version is not present, and then suggest that a consumer which is capable of the 'rev A' (or whatever it is called) flow either a) puts a new (TBD) version indicator in oauth_version or b) omits oauth_version. I think an explicit indication of 1.0 in oauth_version should relate exactly and only to the OAuth 1.0 core specification. If there are parameters there which are not part of the 1.0 flow, however, the SP should be free to do what it wants (ie. give the notice to the user as described below, flag an error to the consumer, or carry on in a way determined by the SP) The same should be done by the consumer (if the oauth_version says 1.0 but the SP includes parameters which are from 'rev a' then it is free to act according to rev a, or to flag an error). > > > - If the version = 1.0 (or not present) and the oauth_callback > parameter *is* present upon sending the user to the authorization > endpoint, the consumer should be assumed broken (i.e., OAuth 1.0 > without Rev. A.) and a notice indicating as such should be displayed > to the user. For example: "We cannot safely identify the service that > sent you here. Please contact them <include contact info for service> > and encourage them to upgrade their integration with <service > provider>." or something to that effect. Agreed, roughly, as this is the consumer behaviour we know to be risky. > > > - Upon redirect (i.e., not desktop/mobile flow), if a verification > code is sent, but the consumer does not include it in the request > token exchange step, produce an error and refuse to continue. This > isn't the greatest experience for the end user, but hopefully > consumers will get complaints "It didn't work!" that way, and will fix > it. > > No version changes required, no "oob" value for the callback parameter > required, either. If we essentially use the presence of oauth_callback in the first request as a version indicator, then I think it needs to have a value in all cases where the consumer intends to perform the new flow, even if the consumer is not capable of performing the in-band callback. Regards, - johnk > > > b. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
