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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/