--- 1/draft-ietf-oauth-saml2-bearer-22.txt	2014-11-12 16:14:51.801740776 -0800
+++ 2/draft-ietf-oauth-saml2-bearer-23.txt	2014-11-12 16:14:51.841741743 -0800
@@ -1,22 +1,22 @@
 
 OAuth Working Group                                          B. Campbell
 Internet-Draft                                             Ping Identity
 Intended status: Standards Track                            C. Mortimore
-Expires: April 24, 2015                                       Salesforce
+Expires: May 16, 2015                                         Salesforce
                                                                 M. Jones
                                                                Microsoft
-                                                        October 21, 2014
+                                                       November 12, 2014
 
  SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
                                  Grants
-                    draft-ietf-oauth-saml2-bearer-22
+                    draft-ietf-oauth-saml2-bearer-23
 
 Abstract
 
    This specification defines the use of a Security Assertion Markup
    Language (SAML) 2.0 Bearer Assertion as a means for requesting an
    OAuth 2.0 access token as well as for use as a means of client
    authentication.
 
 Status of This Memo
 
@@ -26,21 +26,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on April 24, 2015.
+   This Internet-Draft will expire on May 16, 2015.
 
 Copyright Notice
 
    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -506,21 +506,21 @@
    The specification does not mandate replay protection for the SAML
    assertion usage for either the authorization grant or for client
    authentication.  It is an optional feature, which implementations may
    employ at their own discretion.
 
 7.  Privacy Considerations
 
    A SAML Assertion may contain privacy-sensitive information and, to
    prevent disclosure of such information to unintended parties, should
    only be transmitted over encrypted channels, such as TLS.  In cases
-   where it is desirable to prevent disclosure of certain information
+   where it is desirable to prevent disclosure of certain information to
    the client, the Subject and/or individual attributes of a SAML
    Assertion should be encrypted to the authorization server.
 
    Deployments should determine the minimum amount of information
    necessary to complete the exchange and include only that information
    in an Assertion (typically by limiting what information is included
    in an <AttributeStatement> or omitting it altogether).  In some
    cases, the Subject can be a value representing an anonymous or
    pseudonymous user, as described in Section 6.3.1 of the Assertion
    Framework for OAuth 2.0 Client Authentication and Authorization
@@ -646,20 +646,25 @@
    The following people contributed wording and concepts to this
    document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran
    Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten
    Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes
    Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar.
 
 Appendix B.  Document History
 
    [[ to be removed by RFC editor before publication as an RFC ]]
 
+   draft-ietf-oauth-saml2-bearer-23
+
+   o  Fix typo per http://www.ietf.org/mail-archive/web/oauth/current/
+      msg13790.html
+
    draft-ietf-oauth-saml2-bearer-22
 
    o  Changes/suggestions from IESG reviews.
 
    draft-ietf-oauth-saml2-bearer-21
 
    o  Added Privacy Considerations section per AD review discussion
       http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html
       and http://www.ietf.org/mail-archive/web/oauth/current/
       msg13144.html
@@ -779,25 +785,24 @@
    o  Removed text about limited lifetime access tokens and the SHOULD
       NOT on issuing refresh tokens.  The text was moved to draft-ietf-
       oauth-assertions-02 and somewhat modified per http://www.ietf.org/
       mail-archive/web/oauth/current/msg08298.html.
 
    o  Fixed typo/missing word per http://www.ietf.org/mail-
       archive/web/oauth/current/msg08733.html.
 
    o  Added Terminology section.
 
-   draft-ietf-oauth-saml2-bearer-10
-
    o  fix a spelling mistake
 
    draft-ietf-oauth-saml2-bearer-09
+
    o  Attempt to address an ambiguity around validation requirements
       when the Conditions element contain a NotOnOrAfter and
       SubjectConfirmation/SubjectConfirmationData does too.  Basically
       it needs to have at least one bearer SubjectConfirmation element
       but that element can omit SubjectConfirmationData, if Conditions
       has an expiry on it.  Otherwise, a valid SubjectConfirmation must
       have a SubjectConfirmationData with Recipient and NotOnOrAfter.
       And any SubjectConfirmationData that has those elements needs to
       have them checked.