One more issue:, section 3 states: "...the authorization server issues an access token response as described in Section 4.2 of [I-D.ietf.oauth-v2]. The new access token SHOULD have the same expiration and scope as the OAuth 1.0 token which the client is upgrading."
First, only access tokens are mentioned here, and I think both refresh and access tokens should be mentioned. Second, it is the refresh token that should have same expiration as the OAuth 1 token, and not the access token. Marius On Wed, Dec 29, 2010 at 5:40 PM, Marius Scurtescu <mscurte...@google.com> wrote: > Hi David, > > A few suggestions for this extension. I am assuming that you will > update it soon to conform to draft 11 of the core protocol. > > > 1. Instead of passing an assertion why not treat it as another grant > type and pass all parameters as POST parameters. For example: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=http%3A%2F%2Foauth.net%2Ftoken%2F1.0& > oauth_token=rjmaGaw9ATW& > oauth_token_secret=OgFcfEjBR& > client_id=8eSEIpnqmM& > client_secret=s6BhdRkqt3 > > > 2. I think it should also require the OAuth 1 consumer key and secret. > Maybe the assumption was that these are the same as the OAuth 2 client > id and secret, but that may not always be the case. Example: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=http%3A%2F%2Foauth.net%2Ftoken%2F1.0& > oauth_token=rjmaGaw9ATW& > oauth_token_secret=OgFcfEjBR& > oauth_consumer_key=8eSEIpnqmM& > oauth_consumer_secret=s6BhdRkqt3 > client_id=8eSEIpnqmM& > client_secret=s6BhdRkqt3 > > > Marius > > > > On Fri, Aug 27, 2010 at 1:26 PM, David Recordon <record...@gmail.com> wrote: >> This draft is now an Internet Draft and I'm curious if anyone has any >> feedback on >> it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00 >> I'd also like to request that this draft moves to become a Working Group >> item. I'm am happy to act as the editor unless someone else wishes to do so >> moving forward. >> Thanks, >> --David >> >> On Mon, Jul 12, 2010 at 10:39 PM, David Recordon <record...@gmail.com> >> wrote: >>> >>> The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access >>> tokens has come up on the list a few times. Attached is a draft assertion >>> format which allows a client to trade an OAuth 1.0 token/secret pair for an >>> OAuth 2.0 access token. The assertion format is a JSON object with values >>> for the token and token secret. My goal is that this draft become a working >>> group document. >>> A question for the group is if upgrading multiple tokens at once is >>> a necessary use case? The assertion format within the core spec only >>> supports issuing a single access token. Facebook has a custom endpoint which >>> allows upgrading multiple tokens at once, but I don't actually have data >>> about how many developers make use of that functionality. >>> Thanks, >>> --David >> >> _______________________________________________ >> 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
