< draft-ietf-oauth-assertions-13.txt   draft-ietf-oauth-assertions-14.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: June 12, 2014 Salesforce Expires: August 4, 2014 Salesforce
M. Jones M. Jones
Y. Goland Y. Goland
Microsoft Microsoft
December 9, 2013 January 31, 2014
Assertion Framework for OAuth 2.0 Client Authentication and Assertion Framework for OAuth 2.0 Client Authentication and
Authorization Grants Authorization Grants
draft-ietf-oauth-assertions-13 draft-ietf-oauth-assertions-14
Abstract Abstract
This specification provides a framework for the use of assertions This specification provides a framework for the use of assertions
with OAuth 2.0 in the form of a new client authentication mechanism with OAuth 2.0 in the form of a new client authentication mechanism
and a new authorization grant type. Mechanisms are specified for and a new authorization grant type. Mechanisms are specified for
transporting assertions during interactions with a token endpoint, as transporting assertions during interactions with a token endpoint, as
well as general processing rules. well as general processing rules.
The intent of this specification is to provide a common framework for The intent of this specification is to provide a common framework for
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 June 12, 2014. This Internet-Draft will expire on August 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.2. Using Assertions for Client Authentication . . . . . . . 8 4.2. Using Assertions for Client Authentication . . . . . . . 8
4.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 9 4.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 9
5. Assertion Content and Processing . . . . . . . . . . . . . . 10 5. Assertion Content and Processing . . . . . . . . . . . . . . 10
5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 10 5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 10
5.2. General Assertion Format and Processing Rules . . . . . . 11 5.2. General Assertion Format and Processing Rules . . . . . . 11
6. Common Scenarios . . . . . . . . . . . . . . . . . . . . . . 12 6. Common Scenarios . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Client Authentication . . . . . . . . . . . . . . . . . . 12 6.1. Client Authentication . . . . . . . . . . . . . . . . . . 12
6.2. Client Acting on Behalf of Itself . . . . . . . . . . . . 12 6.2. Client Acting on Behalf of Itself . . . . . . . . . . . . 12
6.3. Client Acting on Behalf of a User . . . . . . . . . . . . 13 6.3. Client Acting on Behalf of a User . . . . . . . . . . . . 13
6.3.1. Client Acting on Behalf of an Anonymous User . . . . 13 6.3.1. Client Acting on Behalf of an Anonymous User . . . . 13
7. Interoperability Considerations . . . . . . . . . . . . . . . 14 7. Interoperability Considerations . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Forged Assertion . . . . . . . . . . . . . . . . . . . . 15 8.1. Forged Assertion . . . . . . . . . . . . . . . . . . . . 15
8.2. Stolen Assertion . . . . . . . . . . . . . . . . . . . . 15 8.2. Stolen Assertion . . . . . . . . . . . . . . . . . . . . 15
8.3. Unauthorized Disclosure of Personal Information . . . . . 15 8.3. Unauthorized Disclosure of Personal Information . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. assertion Parameter Registration . . . . . . . . . . . . 16 9.1. assertion Parameter Registration . . . . . . . . . . . . 16
9.2. client_assertion Parameter Registration . . . . . . . . . 17 9.2. client_assertion Parameter Registration . . . . . . . . . 17
9.3. client_assertion_type Parameter Registration . . . . . . 17 9.3. client_assertion_type Parameter Registration . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
skipping to change at page 5, line 12 skipping to change at page 5, line 12
entity is known as a "Security Token Service" (STS) or just "Token entity is known as a "Security Token Service" (STS) or just "Token
Service" and a trust relationship (usually manifested in the exchange Service" and a trust relationship (usually manifested in the exchange
of some kind of key material) exists between the token service and of some kind of key material) exists between the token service and
the relying party. The token service is the assertion issuer; its the relying party. The token service is the assertion issuer; its
role is to fulfill requests from clients, which present various role is to fulfill requests from clients, which present various
credentials, and mint assertions as requested, fill them with credentials, and mint assertions as requested, fill them with
appropriate information, and integrity protect them with a signature appropriate information, and integrity protect them with a signature
or message authentication code. WS-Trust [OASIS.WS-Trust] is one or message authentication code. WS-Trust [OASIS.WS-Trust] is one
available standard for requesting security tokens (assertions). available standard for requesting security tokens (assertions).
Relying Relying
Party Client Token Service Party Client Token Service
| | | | | |
| | 1) Request Assertion | | | 1) Request Assertion |
| |------------------------>| | |------------------------>|
| | | | | |
| | 2) Assertion | | | 2) Assertion |
| |<------------------------| | |<------------------------|
| 3) Assertion | | | 3) Assertion | |
|<-------------------------| | |<-------------------------| |
| | | | | |
| 4) OK or Failure | | | 4) OK or Failure | |
|------------------------->| | |------------------------->| |
| | | | | |
| | | | | |
Figure 1: Third Party Created Assertion Figure 1: Third Party Created Assertion
In the second pattern, depicted in Figure 2, the client creates In the second pattern, depicted in Figure 2, the client creates
assertions locally. To apply the signatures or message assertions locally. To apply the signatures or message
authentication codes to assertions, it has to obtain key material: authentication codes to assertions, it has to obtain key material:
either symmetric keys or asymmetric key pairs. The mechanisms for either symmetric keys or asymmetric key pairs. The mechanisms for
obtaining this key material are beyond the scope of this obtaining this key material are beyond the scope of this
specification. specification.
Although assertions are usually used to convey identity and security Although assertions are usually used to convey identity and security
information, self-issued assertions can also serve a different information, self-issued assertions can also serve a different
purpose. They can be used to demonstrate knowledge of some secret, purpose. They can be used to demonstrate knowledge of some secret,
such as a client secret, without actually communicating the secret such as a client secret, without actually communicating the secret
directly in the transaction. In that case, additional information directly in the transaction. In that case, additional information
included in the assertion by the client itself will be of limited included in the assertion by the client itself will be of limited
value to the relying party and, for this reason, only a bare minimum value to the relying party and, for this reason, only a bare minimum
of information is typically included in such an assertion, such as of information is typically included in such an assertion, such as
information about issuing and usage conditions. information about issuing and usage conditions.
Relying Relying
Party Client Party Client
| | | |
| | 1) Create | | 1) Create
| | Assertion | | Assertion
| |--------------+ | |--------------+
| | | | | |
| | 2) Assertion | | | 2) Assertion |
| |<-------------+ | |<-------------+
| 3) Assertion | | 3) Assertion |
|<-------------------------| |<-------------------------|
| | | |
| 4) OK or Failure | | 4) OK or Failure |
|------------------------->| |------------------------->|
| | | |
| | | |
Figure 2: Self-Issued Assertion Figure 2: Self-Issued Assertion
Deployments need to determine the appropriate variant to use based on Deployments need to determine the appropriate variant to use based on
the required level of security, the trust relationship between the the required level of security, the trust relationship between the
entities, and other factors. entities, and other factors.
From the perspective of what must be done by the entity presenting From the perspective of what must be done by the entity presenting
the assertion, there are two general types of assertions: the assertion, there are two general types of assertions:
skipping to change at page 16, line 42 skipping to change at page 16, line 37
For the cases where a third party token service creates assertions For the cases where a third party token service creates assertions
to be used for client authentication, privacy concerns are to be used for client authentication, privacy concerns are
typically lower, since many of these clients are Web servers typically lower, since many of these clients are Web servers
rather than individual devices operated by humans. If the rather than individual devices operated by humans. If the
assertions are used for client authentication of devices or assertions are used for client authentication of devices or
software that can be closely linked to end users, then privacy software that can be closely linked to end users, then privacy
protection safeguards need to be taken into consideration. protection safeguards need to be taken into consideration.
Further guidance on privacy friendly protocol design can be found Further guidance on privacy friendly protocol design can be found
in [I-D.iab-privacy-considerations]. in [RFC6973].
9. IANA Considerations 9. IANA Considerations
This is a request to add three values, as listed in the sub-sections This is a request to add three values, as listed in the sub-sections
below, to the "OAuth Parameters" registry established by RFC 6749 below, to the "OAuth Parameters" registry established by RFC 6749
[RFC6749]. [RFC6749].
9.1. assertion Parameter Registration 9.1. assertion Parameter Registration
o Parameter name: assertion o Parameter name: assertion
o Parameter usage location: token request o Parameter usage location: token request
o Change controller: IETF o Change controller: IETF
o Specification document(s): [[this document]] o Specification document(s): [[this document]]
9.2. client_assertion Parameter Registration 9.2. client_assertion Parameter Registration
o Parameter name: client_assertion o Parameter name: client_assertion
o Parameter usage location: token request o Parameter usage location: token request
o Change controller: IETF o Change controller: IETF
skipping to change at page 17, line 48 skipping to change at page 17, line 42
[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.
[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.
10.2. Informative References 10.2. Informative References
[I-D.iab-privacy-considerations]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", draft-iab-privacy-
considerations-09 (work in progress), May 2013.
[I-D.ietf-oauth-dyn-reg] [I-D.ietf-oauth-dyn-reg]
Richer, J., Bradley, J., Jones, M., and M. Machulak, Richer, J., Bradley, J., Jones, M., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Protocol", draft- "OAuth 2.0 Dynamic Client Registration Protocol", draft-
ietf-oauth-dyn-reg-13 (work in progress), July 2013. ietf-oauth-dyn-reg-15 (work in progress), July 2013.
[I-D.ietf-oauth-jwt-bearer] [I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer (work Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), December 2013. in progress), December 2013.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
skipping to change at page 18, line 34 skipping to change at page 18, line 19
in progress), December 2013. in progress), December 2013.
[OASIS.WS-Trust] [OASIS.WS-Trust]
Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed., Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed.,
Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust", Feb Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust", Feb
2009. 2009.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012. for OAuth", RFC 6755, October 2012.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July
2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank the following people that have influenced The authors wish to thank the following people that have influenced
or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai, or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai,
Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP
specification, and the members of the OAuth working group. specification, and the members of the OAuth working group.
Appendix B. Document History Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
draft-ietf-oauth-assertions-14
o Update reference: draft-iab-privacy-considerations is now RFC 6973
o Update reference: draft-ietf-oauth-dyn-reg from -13 to -15
draft-ietf-oauth-assertions-13 draft-ietf-oauth-assertions-13
o Clean up language around subject per the subject part of http:// o Clean up language around subject per the subject part of 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_" o Replace "Client Credentials flow" by "Client Credentials _Grant_"
as suggested in http://www.ietf.org/mail-archive/web/oauth/current as suggested in http://www.ietf.org/mail-archive/web/oauth/current
/msg12155.html /msg12155.html
o For consistency with SAML and JWT per http://www.ietf.org/mail- o For consistency with SAML and JWT per http://www.ietf.org/mail-
skipping to change at page 21, line 4 skipping to change at page 20, line 45
draft-ietf-oauth-assertions-06 draft-ietf-oauth-assertions-06
o Add more text to intro explaining that an assertion grant type can o Add more text to intro explaining that an assertion grant type can
be used with or without client authentication/identification and be used with or without client authentication/identification and
that client assertion authentication is nothing more than an that client assertion authentication is nothing more than an
alternative way for a client to authenticate to the token endpoint alternative way for a client to authenticate to the token endpoint
draft-ietf-oauth-assertions-05 draft-ietf-oauth-assertions-05
o Non-normative editorial cleanups o Non-normative editorial cleanups
draft-ietf-oauth-assertions-04
o Updated document to incorporate the review comments from the o Updated document to incorporate the review comments from the
shepherd - thread and alternative draft at http://www.ietf.org/ shepherd - thread and alternative draft at http://www.ietf.org/
mail-archive/web/oauth/current/msg09437.html mail-archive/web/oauth/current/msg09437.html
o Added reference to draft-ietf-oauth-urn-sub-ns and include o Added reference to draft-ietf-oauth-urn-sub-ns and include
suggestions on urn:ietf:params:oauth:[grant-type|client-assertion- suggestions on urn:ietf:params:oauth:[grant-type|client-assertion-
type]:* URNs type]:* URNs
draft-ietf-oauth-assertions-03 draft-ietf-oauth-assertions-03
 End of changes. 16 change blocks. 
46 lines changed or deleted 54 lines changed or added

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