Thanks Eran, Best regards, Diogo Almeida
On Jul 6, 2010, at 3:03 PM, Eran Hammer-Lahav wrote: > > > > > On Jul 3, 2010, at 7:50, Diogo Almeida <[email protected]> wrote: > >> Good afternoon, >> >> I would like to ask the WG two questions regarding -09 >> >> 1) >> On section 3.1, regarding the scope parameter, it reads: >> >> code >> REQUIRED if the response type is "token" or "code-and-token", otherwise MUST >> NOT be included. The authorization code generated by the authorization >> server. The authorization code SHOULD expire shortly after it is issued. The >> authorization server MUST invalidate the authorization code after a single >> usage. The authorization code is bound to the client identifier and >> redirection URI. >> >> Question: Is it a typo that the "code" parameter is REQUIRED if the response >> type is "token" or "code-and-token", rather than "code" or "code-and-token"? >> >> > > Yes. That's a typo. > >> 2) >> Also in section 3.1 or -09, it's stated that the Authorization Response >> contains the parameters: "code", "access_token", "expires_in", "scope" and >> "state". >> >> Question: Would it make sense to also include an OPTIONAL "refresh_token" to >> make this response more in line with section 4.2. Access Token Response. Or >> the intention behind the decision of not returning a "refresh_token" here >> was to make it so that the "access_token" cannot be refreshed this way? > > > Refresh token is only returned when a client secret is present (or other > authentication scheme). > > EHL > >> Best regards, >> Diogo Almeida >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
