- 4.1. Authorization Code. It is stated that authorization code is suitable for clients that can hold a secret. Not necessarily true, it is the best flow for native apps, for example.
- 4.1.2 Authorization Response. Minor typo in last sentence on page 16: "size of any value is issues" => "size of any value it issues"? - 4.1.3. Access Token Request. redirect_uri is required, and must match the one in the original request. But the one in the original request is sort of optional (if registration provides one). - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that the client MUST discard the credentials once it obtains an access token. I think it SHOULD discard once it obtains a *refresh* token. - 4.5. Extensions. For new grant types, we are not using a registry. Is that OK? - 5.2. Error Response. The fist part of the first paragraph talks about 401 and client credentials in the Authorization header. Since this was dropped from core, this looks strange. And there are the other two issues I raised in a separate thread. Thanks, Marius On Wed, Jan 26, 2011 at 12:59 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > I plan to publish a quick fix to editorial issues raised in a -13 on Monday > 1/31. If you have editorial feedback, please post it to the list by Friday > 1/28 so that I can respond and incorporate if needed. This is not a deadline > for normative issues, only editorial, but you can post feedback on both. I > plan to request an official WG review of -13 to begin next week. > > > > EHL > > _______________________________________________ > 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
