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