draft-ietf-oauth-saml2-bearer-21.txt   draft-ietf-oauth-saml2-bearer-22.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: January 24, 2015 Salesforce Expires: April 24, 2015 Salesforce
M. Jones M. Jones
Microsoft Microsoft
July 23, 2014 October 21, 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-21 draft-ietf-oauth-saml2-bearer-22
Abstract Abstract
This specification defines the use of a SAML 2.0 Bearer Assertion as This specification defines the use of a Security Assertion Markup
a means for requesting an OAuth 2.0 access token as well as for use Language (SAML) 2.0 Bearer Assertion as a means for requesting an
as a means of client authentication. OAuth 2.0 access token as well as for use as a means of client
authentication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 24, 2015. This Internet-Draft will expire on April 24, 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 2, line 29 skipping to change at page 2, line 30
5. Interoperability Considerations . . . . . . . . . . . . . . . 11 5. Interoperability Considerations . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Sub-Namespace Registration of urn:ietf:params:oauth 8.1. Sub-Namespace Registration of urn:ietf:params:oauth
:grant-type:saml2-bearer . . . . . . . . . . . . . . . . 12 :grant-type:saml2-bearer . . . . . . . . . . . . . . . . 12
8.2. Sub-Namespace Registration of urn:ietf:params:oauth 8.2. Sub-Namespace Registration of urn:ietf:params:oauth
:client-assertion-type:saml2-bearer . . . . . . . . . . . 12 :client-assertion-type:saml2-bearer . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Security Assertion Markup Language (SAML) 2.0 The Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] is an XML-based framework that allows [OASIS.saml-core-2.0-os] is an XML-based framework that allows
identity and security information to be shared across security identity and security information to be shared across security
domains. The SAML specification, while primarily targeted at domains. The SAML specification, while primarily targeted at
providing cross domain Web browser single sign-on, was also designed providing cross domain Web browser single sign-on, was also designed
to be modular and extensible to facilitate use in other contexts. to be modular and extensible to facilitate use in other contexts.
The Assertion, an XML security token, is a fundamental construct of The Assertion, an XML security token, is a fundamental construct of
SAML that is often adopted for use in other protocols and SAML that is often adopted for use in other protocols and
specifications. An Assertion is generally issued by an identity specifications. (Some examples include [OASIS.WSS-SAMLTokenProfile]
and [OASIS.WS-Fed].) An Assertion is generally issued by an identity
provider and consumed by a service provider who relies on its content provider and consumed by a service provider who relies on its content
to identify the Assertion's subject for security related purposes. to identify the Assertion's subject for security related purposes.
The OAuth 2.0 Authorization Framework [RFC6749] provides a method for The OAuth 2.0 Authorization Framework [RFC6749] provides a method for
making authenticated HTTP requests to a resource using an access making authenticated HTTP requests to a resource using an access
token. Access tokens are issued to third-party clients by an token. Access tokens are issued to third-party clients by an
authorization server (AS) with the (sometimes implicit) approval of authorization server (AS) with the (sometimes implicit) approval of
the resource owner. In OAuth, an authorization grant is an abstract the resource owner. In OAuth, an authorization grant is an abstract
term used to describe intermediate credentials that represent the term used to describe intermediate credentials that represent the
resource owner authorization. An authorization grant is used by the resource owner authorization. An authorization grant is used by the
skipping to change at page 4, line 37 skipping to change at page 4, line 39
The Assertion Framework for OAuth 2.0 Client Authentication and The Assertion Framework for OAuth 2.0 Client Authentication and
Authorization Grants [I-D.ietf-oauth-assertions] specification Authorization Grants [I-D.ietf-oauth-assertions] specification
defines generic HTTP parameters for transporting Assertions during defines generic HTTP parameters for transporting Assertions during
interactions with a token endpoint. This section defines specific interactions with a token endpoint. This section defines specific
parameters and treatments of those parameters for use with SAML 2.0 parameters and treatments of those parameters for use with SAML 2.0
Bearer Assertions. Bearer Assertions.
2.1. Using SAML Assertions as Authorization Grants 2.1. Using SAML Assertions as Authorization Grants
To use a SAML Bearer Assertion as an authorization grant, use an To use a SAML Bearer Assertion as an authorization grant, the client
access token request as defined in Section 4 of the Assertion uses an access token request as defined in Section 4 of the Assertion
Framework for OAuth 2.0 Client Authentication and Authorization Framework for OAuth 2.0 Client Authentication and Authorization
Grants [I-D.ietf-oauth-assertions] specification with the following Grants [I-D.ietf-oauth-assertions] specification with the following
specific parameter values and encodings. specific parameter values and encodings.
The value of the "grant_type" parameter MUST be The value of the "grant_type" parameter is
"urn:ietf:params:oauth:grant-type:saml2-bearer". "urn:ietf:params:oauth:grant-type:saml2-bearer".
The value of the "assertion" parameter MUST contain a single SAML 2.0 The value of the "assertion" parameter contains a single SAML 2.0
Assertion. The SAML Assertion XML data MUST be encoded using Assertion. It MUST NOT contain more than one SAML 2.0 assertion.
base64url, where the encoding adheres to the definition in Section 5 The SAML Assertion XML data MUST be encoded using base64url, where
of RFC 4648 [RFC4648] and where the padding bits are set to zero. To the encoding adheres to the definition in Section 5 of RFC 4648
avoid the need for subsequent encoding steps (by "application/x-www-
form-urlencoded" [W3C.REC-html401-19991224], for example), the [RFC4648] and where the padding bits are set to zero. To avoid the
base64url encoded data SHOULD NOT be line wrapped and pad characters need for subsequent encoding steps (by "application/x-www-form-
("=") SHOULD NOT be included. urlencoded" [W3C.REC-html401-19991224], for example), the base64url
encoded data MUST NOT be line wrapped and pad characters ("=") MUST
NOT be included.
The "scope" parameter may be used, as defined in the Assertion The "scope" parameter may be used, as defined in the Assertion
Framework for OAuth 2.0 Client Authentication and Authorization Framework for OAuth 2.0 Client Authentication and Authorization
Grants [I-D.ietf-oauth-assertions] specification, to indicate the Grants [I-D.ietf-oauth-assertions] specification, to indicate the
requested scope. requested scope.
Authentication of the client is optional, as described in Authentication of the client is optional, as described in
Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the
"client_id" is only needed when a form of client authentication that "client_id" is only needed when a form of client authentication that
relies on the parameter is used. relies on the parameter is used.
The following non-normative example demonstrates an Access Token The following example demonstrates an Access Token Request with an
Request with an assertion as an authorization grant (with extra line assertion as an authorization grant (with extra line breaks for
breaks for display purposes only): display purposes only):
POST /token.oauth2 HTTP/1.1 POST /token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer&
assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4
2.2. Using SAML Assertions for Client Authentication 2.2. Using SAML Assertions for Client Authentication
To use a SAML Bearer Assertion for client authentication, use the To use a SAML Bearer Assertion for client authentication, the client
following parameter values and encodings. uses the following parameter values and encodings.
The value of the "client_assertion_type" parameter MUST be The value of the "client_assertion_type" parameter is
"urn:ietf:params:oauth:client-assertion-type:saml2-bearer". "urn:ietf:params:oauth:client-assertion-type:saml2-bearer".
The value of the "client_assertion" parameter MUST contain a single The value of the "client_assertion" parameter MUST contain a single
SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded
using base64url, where the encoding adheres to the definition in using base64url, where the encoding adheres to the definition in
Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to
zero. To avoid the need for subsequent encoding steps (by zero. To avoid the need for subsequent encoding steps (by
"application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for
example), the base64url encoded data SHOULD NOT be line wrapped and example), the base64url encoded data SHOULD NOT be line wrapped and
pad characters ("=") SHOULD NOT be included. pad characters ("=") SHOULD NOT be included.
The following non-normative example demonstrates a client The following example demonstrates a client authenticating using an
authenticating using an assertion during the presentation of an assertion during the presentation of an authorization code grant in
authorization code grant in an Access Token Request (with extra line an Access Token Request (with extra line breaks for display purposes
breaks for display purposes only): only):
POST /token.oauth2 HTTP/1.1 POST /token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code& grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth client_assertion_type=urn%3Aietf%3Aparams%3Aoauth
%3Aclient-assertion-type%3Asaml2-bearer& %3Aclient-assertion-type%3Asaml2-bearer&
client_assertion=PHNhbW...[omitted for brevity]...ZT client_assertion=PHNhbW...[omitted for brevity]...ZT
skipping to change at page 6, line 39 skipping to change at page 6, line 39
2. The Assertion MUST contain a <Conditions> element with an 2. The Assertion MUST contain a <Conditions> element with an
<AudienceRestriction> element with an <Audience> element that <AudienceRestriction> element with an <Audience> element that
identifies the authorization server as an intended audience. identifies the authorization server as an intended audience.
Section 2.5.1.4 of Assertions and Protocols for the OASIS Section 2.5.1.4 of Assertions and Protocols for the OASIS
Security Assertion Markup Language [OASIS.saml-core-2.0-os] Security Assertion Markup Language [OASIS.saml-core-2.0-os]
defines the <AudienceRestriction> and <Audience> elements and, defines the <AudienceRestriction> and <Audience> elements and,
in addition to the URI references discussed there, the token in addition to the URI references discussed there, the token
endpoint URL of the authorization server MAY be used as a URI endpoint URL of the authorization server MAY be used as a URI
that identifies the authorization server as an intended that identifies the authorization server as an intended
audience. Assertions that do not identify the Authorization audience. The Authorization Server MUST reject any assertion
Server as an intended audience MUST be rejected. In the absence that does not contain its own identity as the intended audience.
of an application profile specifying otherwise, compliant In the absence of an application profile specifying otherwise,
applications MUST compare the audience values using the Simple compliant applications MUST compare the audience values using
String Comparison method defined in Section 6.2.1 of RFC 3986 the Simple String Comparison method defined in Section 6.2.1 of
[RFC3986]. RFC 3986 [RFC3986]. As noted in Section 5, the precise strings
to be used as the audience for a given Authorization Server must
be configured out-of-band by the Authorization Server and the
Issuer of the assertion.
3. The Assertion MUST contain a <Subject> element identifying the 3. The Assertion MUST contain a <Subject> element identifying the
principal that is the subject of the Assertion. Additional principal that is the subject of the Assertion. Additional
information identifying the subject/principal MAY be included in information identifying the subject/principal MAY be included in
an <AttributeStatement>. an <AttributeStatement>.
A. For the authorization grant, the Subject typically A. For the authorization grant, the Subject typically
identifies an authorized accessor for which the access token identifies an authorized accessor for which the access token
is being requested (i.e., the resource owner or an is being requested (i.e., the resource owner or an
authorized delegate), but in some cases, may be a authorized delegate), but in some cases, may be a
skipping to change at page 7, line 20 skipping to change at page 7, line 23
"client_id" of the OAuth client. "client_id" of the OAuth client.
4. The Assertion MUST have an expiry that limits the time window 4. The Assertion MUST have an expiry that limits the time window
during which it can be used. The expiry can be expressed either during which it can be used. The expiry can be expressed either
as the NotOnOrAfter attribute of the <Conditions> element or as as the NotOnOrAfter attribute of the <Conditions> element or as
the NotOnOrAfter attribute of a suitable the NotOnOrAfter attribute of a suitable
<SubjectConfirmationData> element. <SubjectConfirmationData> element.
5. The <Subject> element MUST contain at least one 5. The <Subject> element MUST contain at least one
<SubjectConfirmation> element that has a Method attribute with a <SubjectConfirmation> element that has a Method attribute with a
value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". The value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". If the
<SubjectConfirmation> element MUST contain a Assertion does not have a suitable NonOnOrAfter attribute on the
<SubjectConfirmationData> element, unless the Assertion has a <Conditions> element, the <SubjectConfirmation> element MUST
suitable NotOnOrAfter attribute on the <Conditions> element, in contain a <SubjectConfirmationData> element. When present, the
which case the <SubjectConfirmationData> element MAY be omitted. <SubjectConfirmationData> element MUST have a Recipient
When present, the <SubjectConfirmationData> element MUST have a attribute with a value indicating the token endpoint URL of the
Recipient attribute with a value indicating the token endpoint authorization server (or an acceptable alias). The
URL of the authorization server (or an acceptable alias). The
authorization server MUST verify that the value of the Recipient authorization server MUST verify that the value of the Recipient
attribute matches the token endpoint URL (or an acceptable attribute matches the token endpoint URL (or an acceptable
alias) to which the Assertion was delivered. The alias) to which the Assertion was delivered. The
<SubjectConfirmationData> element MUST have a NotOnOrAfter <SubjectConfirmationData> element MUST have a NotOnOrAfter
attribute that limits the window during which the Assertion can attribute that limits the window during which the Assertion can
be confirmed. The <SubjectConfirmationData> element MAY also be confirmed. The <SubjectConfirmationData> element MAY also
contain an Address attribute limiting the client address from contain an Address attribute limiting the client address from
which the Assertion can be delivered. Verification of the which the Assertion can be delivered. Verification of the
Address is at the discretion of the authorization server. Address is at the discretion of the authorization server.
6. The authorization server MUST verify that the NotOnOrAfter 6. The authorization server MUST reject the entire Assertion if the
instant has not passed, subject to allowable clock skew between NotOnOrAfter instant on the <Conditions> element has passed
systems. An invalid NotOnOrAfter instant on the <Conditions> (subject to allowable clock skew between systems). The
element invalidates the entire Assertion. An invalid authorization server MUST reject the <SubjectConfirmation> (but
NotOnOrAfter instant on a <SubjectConfirmationData> element only MAY still use the rest of the Assertion) if the NotOnOrAfter
invalidates the individual <SubjectConfirmation>. The instant on the <SubjectConfirmationData> has passed (subject to
authorization server MAY reject Assertions with a NotOnOrAfter allowable clock skew). Note that the authorization server may
instant that is unreasonably far in the future. The reject Assertions with a NotOnOrAfter instant that is
authorization server MAY ensure that Bearer Assertions are not unreasonably far in the future. The authorization server MAY
replayed, by maintaining the set of used ID values for the ensure that Bearer Assertions are not replayed, by maintaining
length of time for which the Assertion would be considered valid the set of used ID values for the length of time for which the
based on the applicable NotOnOrAfter instant. Assertion would be considered valid based on the applicable
NotOnOrAfter instant.
7. If the Assertion issuer authenticated the subject, the Assertion 7. If the Assertion issuer directly authenticated the subject, the
SHOULD contain a single <AuthnStatement> representing that Assertion SHOULD contain a single <AuthnStatement> representing
authentication event. If the Assertion was issued with the that authentication event. If the Assertion was issued with the
intention that the client act autonomously on behalf of the intention that the client act autonomously on behalf of the
subject, an <AuthnStatement> SHOULD NOT be included and the subject, an <AuthnStatement> SHOULD NOT be included and the
client presenting the assertion SHOULD be identified in the client presenting the assertion SHOULD be identified in the
<NameID> or similar element in the <SubjectConfirmation> <NameID> or similar element in the <SubjectConfirmation>
element, or by other available means like SAML V2.0 Condition element, or by other available means like SAML V2.0 Condition
for Delegation Restriction [OASIS.saml-deleg-cs]. for Delegation Restriction [OASIS.saml-deleg-cs].
8. Other statements, in particular <AttributeStatement> elements, 8. Other statements, in particular <AttributeStatement> elements,
MAY be included in the Assertion. MAY be included in the Assertion.
9. The Assertion MUST be digitally signed or have a keyed message 9. The Assertion MUST be digitally signed or have a Message
digest applied by the issuer. The authorization server MUST Authentication Code applied by the issuer. The authorization
reject assertions with an invalid signature or keyed message server MUST reject assertions with an invalid signature or
digest. Message Authentication Code.
10. Encrypted elements MAY appear in place of their plain text 10. Encrypted elements MAY appear in place of their plain text
counterparts as defined in [OASIS.saml-core-2.0-os]. counterparts as defined in [OASIS.saml-core-2.0-os].
11. The authorization server MUST verify that the Assertion is valid 11. The authorization server MUST reject an Assertion that is not
in all other respects per [OASIS.saml-core-2.0-os], such as (but valid in all other respects per [OASIS.saml-core-2.0-os], such
not limited to) evaluating all content within the Conditions as (but not limited to) all content within the Conditions
element including the NotOnOrAfter and NotBefore attributes, element including the NotOnOrAfter and NotBefore attributes,
rejecting unknown condition types, etc. unknown condition types, etc.
3.1. Authorization Grant Processing 3.1. Authorization Grant Processing
Assertion authorization grants may be used with or without client Assertion authorization grants may be used with or without client
authentication or identification. Whether or not client authentication or identification. Whether or not client
authentication is needed in conjunction with an assertion authentication is needed in conjunction with an assertion
authorization grant, as well as the supported types of client authorization grant, as well as the supported types of client
authentication, are policy decisions at the discretion of the authentication, are policy decisions at the discretion of the
authorization server. However, if client credentials are present in authorization server. However, if client credentials are present in
the request, the authorization server MUST validate them. the request, the authorization server MUST validate them.
If the Assertion is not valid (including if its subject confirmation If the Assertion is not valid (including if its subject confirmation
requirements cannot be met), the authorization server MUST construct requirements cannot be met), the authorization server constructs an
an error response as defined in OAuth 2.0 [RFC6749]. The value of error response as defined in OAuth 2.0 [RFC6749]. The value of the
the "error" parameter MUST be the "invalid_grant" error code. The "error" parameter MUST be the "invalid_grant" error code. The
authorization server MAY include additional information regarding the authorization server MAY include additional information regarding the
reasons the Assertion was considered invalid using the reasons the Assertion was considered invalid using the
"error_description" or "error_uri" parameters. "error_description" or "error_uri" parameters.
For example: For example:
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"error":"invalid_grant", "error":"invalid_grant",
"error_description":"Audience validation failed" "error_description":"Audience validation failed"
} }
3.2. Client Authentication Processing 3.2. Client Authentication Processing
If the client Assertion is not valid (including if its subject If the client Assertion is not valid (including if its subject
confirmation requirements cannot be met), the authorization server confirmation requirements cannot be met), the authorization server
MUST construct an error response as defined in OAuth 2.0 [RFC6749]. constructs an error response as defined in OAuth 2.0 [RFC6749]. The
The value of the "error" parameter MUST be the "invalid_client" error value of the "error" parameter MUST be the "invalid_client" error
code. The authorization server MAY include additional information code. The authorization server MAY include additional information
regarding the reasons the Assertion was considered invalid using the regarding the reasons the Assertion was considered invalid using the
"error_description" or "error_uri" parameters. "error_description" or "error_uri" parameters.
4. Authorization Grant Example 4. Authorization Grant Example
Though non-normative, the following examples illustrate what a The following examples illustrate what a conforming Assertion and an
conforming Assertion and access token request would look like. access token request would look like.
The example shows an assertion issued and signed by the SAML Identity The example shows an assertion issued and signed by the SAML Identity
Provider identified as "https://saml-idp.example.com". The subject Provider identified as "https://saml-idp.example.com". The subject
of the assertion is identified by email address as of the assertion is identified by email address as
"brian@example.com", who authenticated to the Identity Provider by "brian@example.com", who authenticated to the Identity Provider by
means of a digital signature where the key was validated as part of means of a digital signature where the key was validated as part of
an X.509 Public Key Infrastructure. The intended audience of the an X.509 Public Key Infrastructure. The intended audience of the
assertion is "https://saml-sp.example.net", which is an identifier assertion is "https://saml-sp.example.net", which is an identifier
for a SAML Service Provider with which the authorization server for a SAML Service Provider with which the authorization server
identifies itself. The assertion is sent as part of an access token identifies itself. The assertion is sent as part of an access token
skipping to change at page 11, line 37 skipping to change at page 11, line 37
signature over the assertion, one-time use restrictions on signature over the assertion, one-time use restrictions on
assertions, maximum assertion lifetime allowed, and the specific assertions, maximum assertion lifetime allowed, and the specific
subject and attribute requirements of the assertion. The exchange of subject and attribute requirements of the assertion. The exchange of
such information is explicitly out of scope for this specification such information is explicitly out of scope for this specification
and typical deployment of it will be done alongside existing SAML Web and typical deployment of it will be done alongside existing SAML Web
SSO deployments that have already established a means of exchanging SSO deployments that have already established a means of exchanging
such information. Metadata for the OASIS Security Assertion Markup such information. Metadata for the OASIS Security Assertion Markup
Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common
method of exchanging SAML related information about system entities. method of exchanging SAML related information about system entities.
The RSA-SHA256 algorithm, from [RFC6931], is a mandatory to implement
XML signature algorithm for this profile.
6. Security Considerations 6. Security Considerations
The security considerations described within the Assertion Framework The security considerations described within the Assertion Framework
for OAuth 2.0 Client Authentication and Authorization Grants for OAuth 2.0 Client Authentication and Authorization Grants
[I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework
[RFC6749], and the Security and Privacy Considerations for the OASIS [RFC6749], and the Security and Privacy Considerations for the OASIS
Security Assertion Markup Language (SAML) V2.0 Security Assertion Markup Language (SAML) V2.0
[OASIS.saml-sec-consider-2.0-os] specifications are all applicable to [OASIS.saml-sec-consider-2.0-os] specifications are all applicable to
this document. this document.
skipping to change at page 12, line 37 skipping to change at page 12, line 39
This is a request to IANA to please register the value "grant- This is a request to IANA to please register the value "grant-
type:saml2-bearer" in the registry urn:ietf:params:oauth established type:saml2-bearer" in the registry urn:ietf:params:oauth established
in An IETF URN Sub-Namespace for OAuth [RFC6755]. in An IETF URN Sub-Namespace for OAuth [RFC6755].
o URN: urn:ietf:params:oauth:grant-type:saml2-bearer o URN: urn:ietf:params:oauth:grant-type:saml2-bearer
o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for
OAuth 2.0 OAuth 2.0
o Change controller: IETF o Change controller: IESG
o Specification Document: [[this document]] o Specification Document: [[this document]]
8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-
assertion-type:saml2-bearer assertion-type:saml2-bearer
This is a request to IANA to please register the value "client- This is a request to IANA to please register the value "client-
assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth
established in An IETF URN Sub-Namespace for OAuth [RFC6755]. established in An IETF URN Sub-Namespace for OAuth [RFC6755].
skipping to change at page 12, line 49 skipping to change at page 13, line 4
o Specification Document: [[this document]] o Specification Document: [[this document]]
8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-
assertion-type:saml2-bearer assertion-type:saml2-bearer
This is a request to IANA to please register the value "client- This is a request to IANA to please register the value "client-
assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth
established in An IETF URN Sub-Namespace for OAuth [RFC6755]. established in An IETF URN Sub-Namespace for OAuth [RFC6755].
o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer
o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0
Client Authentication Client Authentication
o Change controller: IETF o Change controller: IESG
o Specification Document: [[this document]] o Specification Document: [[this document]]
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-oauth-assertions] [I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication "Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", draft-ietf-oauth-assertions and Authorization Grants", draft-ietf-oauth-assertions
(work in progress), July 2014. (work in progress), October 2014.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[OASIS.saml-deleg-cs]
Cantor, S., Ed., "SAML V2.0 Condition for Delegation
Restriction", Nov 2009.
[OASIS.saml-sec-consider-2.0-os]
Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS Standard saml-sec-consider-
2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6931] Eastlake, D., "Additional XML Security Uniform Resource
for OAuth", RFC 6755, October 2012. Identifiers (URIs)", RFC 6931, April 2013.
9.2. Informative References 9.2. Informative References
[OASIS.saml-deleg-cs] [OASIS.WS-Fed]
Cantor, S., Ed., "SAML V2.0 Condition for Delegation Goodner, M. and T. Nadalin, "Web Services Federation
Restriction", Nov 2009. Language (WS-Federation) Version 1.2", May 2009,
<http://docs.oasis-open.org/wsfed/federation/v1.2/os/
ws-federation-1.2-spec-os.html>.
[OASIS.WSS-SAMLTokenProfile]
Monzillo, R., Kaler, C., Nadalin, T., Hallam-Baker, P.,
and C. Milono, "Web Services Security SAML Token Profile
Version 1.1.1", May 2012, <http://docs.oasis-open.org/wss-
m/wss/v1.1.1/wss-SAMLTokenProfile-v1.1.1.html>.
[OASIS.saml-metadata-2.0-os] [OASIS.saml-metadata-2.0-os]
Cantor, S., Moreh, J., Philpott, R., and E. Maler, Cantor, S., Moreh, J., Philpott, R., and E. Maler,
"Metadata for the Security Assertion Markup Language "Metadata for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March
2005. 2005, <http://docs.oasis-open.org/security/saml/v2.0/
saml-metadata-2.0-os.pdf>.
[OASIS.saml-profiles-2.0-os] [OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. Standard OASIS.saml-profiles-2.0-os, March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/
saml-profiles-2.0-os.pdf>.
[OASIS.saml-sec-consider-2.0-os] [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
Hirsch, F., Philpott, R., and E. Maler, "Security and for OAuth", RFC 6755, October 2012.
Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS Standard saml-sec-consider-
2.0-os, March 2005.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
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-22
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
draft-ietf-oauth-saml2-bearer-20 draft-ietf-oauth-saml2-bearer-20
o Clarified some text around the treatment of subject based on the o Clarified some text around the treatment of subject based on the
skipping to change at page 20, line 5 skipping to change at page 20, line 32
o Added Parameter Registration Request for "assertion" to IANA o Added Parameter Registration Request for "assertion" to IANA
Considerations. Considerations.
o Changed document name to draft-ietf-oauth-saml2-bearer in o Changed document name to draft-ietf-oauth-saml2-bearer in
anticipation of becoming an OAUTH WG item. anticipation of becoming an OAUTH WG item.
o Attempt to move the entire definition of the 'assertion' parameter o Attempt to move the entire definition of the 'assertion' parameter
into this draft (it will no longer be defined in OAuth 2 Protocol into this draft (it will no longer be defined in OAuth 2 Protocol
Framework). Framework).
draft-campbell-oauth-saml-01
o Updated to reference draft-ietf-oauth-v2-11 and reflect changes o Updated to reference draft-ietf-oauth-v2-11 and reflect changes
from -10 to -11. from -10 to -11.
o Updated examples. o Updated examples.
o Relaxed processing rules to allow for more than one o Relaxed processing rules to allow for more than one
SubjectConfirmation element. SubjectConfirmation element.
o Removed the 'MUST NOT contain a NotBefore attribute' on o Removed the 'MUST NOT contain a NotBefore attribute' on
SubjectConfirmationData. SubjectConfirmationData.
 End of changes. 38 change blocks. 
93 lines changed or deleted 128 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/