Draft 14 of the OAuth 2.0 Bearer Token Specification<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html> has been published. It contains the following changes:
· Changes made in response to review comments by Security Area Director Stephen Farrell. Specifically: · Strengthened warnings about passing an access token as a query parameter and more precisely described the limitations placed upon the use of this method. · Clarified that the realm attribute MAY included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I‑D.ietf‑httpbis‑p7‑auth]<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#I-D.ietf-httpbis-p7-auth>. · Normatively stated that "the token integrity protection MUST be sufficient to prevent the token from being modified". · Added statement that "TLS is mandatory to implement and use with this specification" to the introduction. · Stated that TLS MUST be used with "a ciphersuite that provides confidentiality and integrity protection". · Added "As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources" to the Threat Mitigation section. · Clarified that putting a validity time field inside the protected part of the token is one means, but not the only means, of limiting the lifetime of the token. · Dropped the confusing phrase "for instance, through the use of TLS" from the sentence about confidentiality protection of the exchanges. · Reference RFC 6125 for identity verification, rather than RFC 2818. · Stated that the token MUST be protected between front end and back end servers when the TLS connection terminates at a front end server that is distinct from the actual server that provides the resource. · Stated that bearer tokens MUST not be stored in cookies that can be sent in the clear in the Threat Mitigation section. · Replaced sole remaining reference to [RFC2616]<http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#RFC2616>. · Replaced all references where the reference is used as if it were part of the sentence (such as "defined by [I-D.whatever]") with ones where the specification name is used, followed by the reference (such as "defined by Whatever [I-D.whatever]"). · Other on-normative editorial improvements. The draft is available at these locations: · http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-14 · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-14.pdf · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-14.txt · http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-14.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-14.html · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-14.pdf · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-14.txt · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-14.xml · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will point to new versions as they are posted) · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will point to new versions as they are posted) · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, pdf, txt, and html versions available) -- Mike
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
