Hi, Antonio. Thanks for the update.
Here is the link for the diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-23.txt The good news is that there are no big changes. One thing I see is the following: Including the client credentials in the request body using the two parameters is NOT RECOMMENDED, and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). The parameters can only be transmitted in the request body and MUST NOT be included in the request URI. The spec update is just in time for us to build a release :-). Thanks, Raymond On Jan 27, 2012, at 2:20 AM, Antonio Sanso wrote: > FYI > > Begin forwarded message: > > From: Mike Jones > <[email protected]<mailto:[email protected]>> > Date: January 23, 2012 6:11:38 PM GMT+01:00 > To: "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Subject: [OAUTH-WG] OAuth specs in IETF last call > > FYI, the OAuth Core and Bearer specifications have reached IETF last call > status - the last step before becoming RFCs. See the following notes from > the Internet Engineering Steering Group (IESG). > > -- Mike > > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]] On Behalf Of The IESG > Sent: Monday, January 23, 2012 7:44 AM > To: IETF-Announce > Cc: [email protected]<mailto:[email protected]> > Subject: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-23.txt> (The OAuth 2.0 > Authorization Protocol) to Proposed Standard > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol' > <draft-ietf-oauth-v2-23.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected]<mailto:[email protected]> mailing lists by 2012-02-06. > Exceptionally, comments may be sent to [email protected]<mailto:[email protected]> > instead. In either case, please retain the beginning of the Subject line to > allow automated sorting. > > Abstract > > > The OAuth 2.0 authorization protocol enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 1.0 protocol described > in RFC 5849. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of The > IESG > Sent: Monday, January 23, 2012 7:47 AM > To: IETF-Announce > Cc: [email protected] > Subject: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth > 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > [email protected] mailing lists by 2012-02-06. Exceptionally, comments may be > sent to [email protected] instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
