Subject: [OAUTH-WG] New Assertion Drafts Published

From: Brian Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 14:29:31 -0700

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>.