New versions of all three OAuth related assertion documents have been published. Links to the htmlized drafts and change logs (mostly clarification resulting from Shepherd review in early November) are listed below. Thanks to Mike Jones for the preliminary review and updates/fixes.
Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-assertions-13 draft-ietf-oauth-assertions-13 <http://tools.ietf.org/html/draft-ietf-oauth-assertions-13> o Clean up language around subject per the subject part of http:// <http://www.ietf.org/mail-archive/web/oauth/current/msg12155.html> www.ietf.org/mail-archive/web/oauth/current/msg12155.html o Replace "Client Credentials flow" by "Client Credentials _Grant_" as suggested in http://www.ietf.org/mail-archive/web/oauth/current <http://www.ietf.org/mail-archive/web/oauth/current/msg12155.html> /msg12155.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12155.html> o For consistency with SAML and JWT per http://www.ietf.org/mail- <http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html> archive/web/oauth/current/msg12251.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html> and http://www.ietf.org/ <http://www.ietf.org/mail-archive/web/oauth/current/msg12253.html> mail-archive/web/oauth/current/msg12253.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12253.html> Stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 <http://tools.ietf.org/html/rfc3986#section-6.2.1>." o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 draft-ietf-oauth-jwt-bearer-07 <http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07> o Clean up language around subject per http://www.ietf.org/mail- <http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html> archive/web/oauth/current/msg12250.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html>. o As suggested in http://www.ietf.org/mail-archive/web/oauth/current <http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html> /msg12251.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html> stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 <http://tools.ietf.org/html/rfc3986#section-6.2.1>." o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations based on http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. o Remove "or its subject confirmation requirements cannot be met" text. o Reword security considerations and mention that replay protection is not mandated based on http://www.ietf.org/mail-archive/web/ <http://www.ietf.org/mail-archive/web/oauth/current/msg12259.html> oauth/current/msg12259.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12259.html>. SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-18 draft-ietf-oauth-saml2-bearer-18 <http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-18> o Clean up language around subject per http://www.ietf.org/mail- <http://www.ietf.org/mail-archive/web/oauth/current/msg12254.html> archive/web/oauth/current/msg12254.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12254.html>. o As suggested in http://www.ietf.org/mail-archive/web/oauth/current <http://www.ietf.org/mail-archive/web/oauth/current/msg12253.html> /msg12253.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12253.html> stated that "In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience/issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 <http://tools.ietf.org/html/rfc3986#section-6.2.1>." o Clarify the potentially confusing language about the AS confirming the assertion http://www.ietf.org/mail-archive/web/oauth/current/ <http://www.ietf.org/mail-archive/web/oauth/current/msg12255.html> msg12255.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12255.html>. o Combine the two items about AuthnStatement and drop the word presenter as discussed in http://www.ietf.org/mail-archive/web/ <http://www.ietf.org/mail-archive/web/oauth/current/msg12257.html> oauth/current/msg12257.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12257.html>. o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations based on http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. o Reword security considerations and mention that replay protection is not mandated based on http://www.ietf.org/mail-archive/web/ <http://www.ietf.org/mail-archive/web/oauth/current/msg12259.html> oauth/current/msg12259.html <http://www.ietf.org/mail-archive/web/oauth/current/msg12259.html>.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
