Chairs - please open an issue for this: "Clarifying reference to refresh tokens in section 1.4.3 of -20".
> -----Original Message----- > From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] > Sent: Thursday, August 18, 2011 1:01 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 > from Yaron Goland > > >> 1.4.3. Resource Owner Password Credentials: Comment on "(when > >> combined with a refresh token)": "This is the first time that refresh > >> tokens are mentioned in the spec. And yet there is no explanation of > what they are. > >> I suspect they should anyway be introduced in section 1.4.1 (as > >> previously > >> noted) and then their use here will make sense. If that isn't > >> possible then it would be good to have a forward reference to section > >> 1.5 below so the reader has some idea of what's going on." > > >I removed '(when combined with a refresh token)'. This is actually not true > as there is no assumption that >access tokens are always short-lived or that > refresh tokens will always be issued to native applications using >this grant > type. > > -1 against removing this text (w/o an suitable replacement) and w/o group > consent. Since you felt it necessary to make this a process issue, I've asked the chairs to open a ticket. > The -20 text clearly points out that this combination "... eliminates the need > for the client to store the resource owner credentials for future use". The > resource owner grant type alone does not justify this statement. > It's true that the spec does not explicitly defines the lifetime assumption > for > access and refresh tokens (which is pity in my opinion). So at least add > something like "if the token lifetime is reasonable long enough". How about: This grant type can eliminates the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token. As for Yaron's original comment, I think this text is sufficient and no forward reference is needed to 1.5 (which is a few lines lower in the same page). Also, with the new organization proposed by Justin, the access token term isn't full defined yet either and it reads just fine. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
