< draft-ietf-oauth-proof-of-possession-04.txt   draft-ietf-oauth-proof-of-possession-05.txt >
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: February 29, 2016 Ping Identity Expires: April 21, 2016 Ping Identity
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
August 28, 2015 October 19, 2015
Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
draft-ietf-oauth-proof-of-possession-04 draft-ietf-oauth-proof-of-possession-05
Abstract Abstract
This specification defines how to express a declaration in a JSON Web This specification defines how to express a declaration in a JSON Web
Token (JWT) that the presenter of the JWT possesses a particular key Token (JWT) that the presenter of the JWT possesses a particular key
and that the recipient can cryptographically confirm proof-of- and that the recipient can cryptographically confirm proof-of-
possession of the key by the presenter. This property is also possession of the key by the presenter. Being able to prove
sometimes described as the presenter being a holder-of-key. possession of a key is also sometimes described as the presenter
being a holder-of-key.
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 February 29, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 15 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Representations for Proof-of-Possession Keys . . . . . . . . . 4 3. Representations for Proof-of-Possession Keys . . . . . . . . . 4
3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . . 5 3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . . 5
3.2. Representation of an Asymmetric Proof-of-Possession Key . 5 3.2. Representation of an Asymmetric Proof-of-Possession Key . 6
3.3. Representation of an Encrypted Symmetric 3.3. Representation of an Encrypted Symmetric
Proof-of-Possession Key . . . . . . . . . . . . . . . . . 6 Proof-of-Possession Key . . . . . . . . . . . . . . . . . 6
3.4. Representation of a Key ID for a Proof-of-Possession 3.4. Representation of a Key ID for a Proof-of-Possession
Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Representation of a URL for a Proof-of-Possession Key . . 8 3.5. Representation of a URL for a Proof-of-Possession Key . . 8
3.6. Specifics Intentionally Not Specified . . . . . . . . . . 8 3.6. Specifics Intentionally Not Specified . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 11 6.1. JSON Web Token Claims Registration . . . . . . . . . . . . 11
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11
6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 11 6.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 11
6.2.1. Registration Template . . . . . . . . . . . . . . . . 11 6.2.1. Registration Template . . . . . . . . . . . . . . . . 11
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This specification defines how to express a declaration in a JSON Web This specification defines how a JSON Web Token (JWT) [JWT] can
Token (JWT) [JWT] that the presenter of the JWT possesses a declare that the presenter of the JWT possesses a key and that the
particular key and that the recipient can cryptographically confirm recipient can cryptographically confirm that the presenter possesses
proof-of-possession of the key by the presenter. This property is that key. Proof-of-possession of a key is also sometimes described
also sometimes described as the presenter being a holder-of-key. See as the presenter being a holder-of-key. The
[I-D.ietf-oauth-pop-architecture] for a further discussion of key [I-D.ietf-oauth-pop-architecture] specification describes key
confirmation. confirmation, among other confirmation mechanisms. This
specification defines how to communicate key confirmation key
information in JWTs.
Envision the following two use cases. The first use case describes Envision the following two use cases. The first use case describes
the use of a symmetric proof-of-possession key and the second use the use of a symmetric proof-of-possession key and the second use
case uses an asymmetric proof-of-possession key. case uses an asymmetric proof-of-possession key.
An issuer generates a JWT and places an encrypted symmetric key An issuer generates a JWT and places an encrypted symmetric key
inside the newly introduced confirmation claim. This symmetric key inside the newly introduced confirmation claim. This symmetric key
is encrypted with a key known only to the issuer and the recipient. is encrypted with a key known only to the issuer and the recipient.
The entire JWT is then integrity protected by the issuer. The JWT is The entire JWT is then integrity protected by the issuer. The JWT is
then sent to the presenter. Since the presenter is unable to obtain then sent to the presenter. Since the presenter is unable to obtain
skipping to change at page 4, line 49 skipping to change at page 5, line 5
3. Representations for Proof-of-Possession Keys 3. Representations for Proof-of-Possession Keys
The issuer of a JWT declares that the presenter possesses a The issuer of a JWT declares that the presenter possesses a
particular key and that the recipient can cryptographically confirm particular key and that the recipient can cryptographically confirm
proof-of-possession of the key by the presenter by including a "cnf" proof-of-possession of the key by the presenter by including a "cnf"
(confirmation) claim in the JWT whose value is a JSON object. (confirmation) claim in the JWT whose value is a JSON object.
Members in the JSON object identify the proof-of-possession key. Members in the JSON object identify the proof-of-possession key.
The presenter can be identified in one of several ways by the JWT, The presenter can be identified in one of several ways by the JWT,
depending upon the application requirements. If the JWT contains a depending upon the application requirements. If the JWT contains a
"sub" (subject) claim, the presenter is normally the subject "sub" (subject) claim [JWT], the presenter is normally the subject
identified by the JWT. (In some applications, the subject identifier identified by the JWT. (In some applications, the subject identifier
will be relative to the issuer identified by the "iss" (issuer) will be relative to the issuer identified by the "iss" (issuer) claim
claim.) If the JWT contains no "sub" (subject) claim, the presenter [JWT].) If the JWT contains no "sub" (subject) claim, the presenter
is normally the issuer identified by the JWT using the "iss" (issuer) is normally the issuer identified by the JWT using the "iss" (issuer)
claim. The case in which the presenter is the subject of the JWT is claim. The case in which the presenter is the subject of the JWT is
analogous to SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation analogous to SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
usage. At least one of the "sub" and "iss" claims MUST be present in usage. At least one of the "sub" and "iss" claims MUST be present in
the JWT. Some use cases may require that both be present. the JWT. Some use cases may require that both be present.
Another means used by some applications to identify the presenter is Another means used by some applications to identify the presenter is
an explicit claim, such as the "azp" (authorized party) claim defined an explicit claim, such as the "azp" (authorized party) claim defined
by OpenID Connect [OpenID.Core]. Ultimately, the means of by OpenID Connect [OpenID.Core]. Ultimately, the means of
identifying the presenter is application-specific, as is the means of identifying the presenter is application-specific, as is the means of
skipping to change at page 5, line 41 skipping to change at page 5, line 44
registry for these members in Section 6.2 and registers the members registry for these members in Section 6.2 and registers the members
defined by this specification. Other specifications can register defined by this specification. Other specifications can register
other members used for confirmation, including other members for other members used for confirmation, including other members for
conveying proof-of-possession keys, possibly using different key conveying proof-of-possession keys, possibly using different key
representations. representations.
Note that if an application needs to represent multiple proof-of- Note that if an application needs to represent multiple proof-of-
possession keys in the same JWT, one way for it to achieve this is to possession keys in the same JWT, one way for it to achieve this is to
use other claim names, in addition to "cnf", to hold the additional use other claim names, in addition to "cnf", to hold the additional
proof-of-possession key information. These claims could use the same proof-of-possession key information. These claims could use the same
syntax and semantics as the "cnf" claim. syntax and semantics as the "cnf" claim. Those claims would be
defined by applications or other specifications and could be
registered in the IANA "JSON Web Token Claims" registry
[IANA.JWT.Claims].
3.2. Representation of an Asymmetric Proof-of-Possession Key 3.2. Representation of an Asymmetric Proof-of-Possession Key
When the key held by the presenter is an asymmetric private key, the When the key held by the presenter is an asymmetric private key, the
"jwk" member is a JSON Web Key (JWK) [JWK] representing the "jwk" member is a JSON Web Key (JWK) [JWK] representing the
corresponding asymmetric public key. The following example corresponding asymmetric public key. The following example
demonstrates such a declaration in the JWT Claims Set of a JWT: demonstrates such a declaration in the JWT Claims Set of a JWT:
{ {
"iss": "https://server.example.com", "iss": "https://server.example.com",
skipping to change at page 13, line 36 skipping to change at page 13, line 41
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
March 2011, <http://www.rfc-editor.org/info/rfc6125>. March 2011, <http://www.rfc-editor.org/info/rfc6125>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-oauth-pop-architecture] [I-D.ietf-oauth-pop-architecture]
Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture", draft-ietf-oauth-pop-architecture-01 (work Architecture", draft-ietf-oauth-pop-architecture-03 (work
in progress), March 2015. in progress), September 2015.
[JWK.Thumbprint] [JWK.Thumbprint]
Jones, M. and N. Sakimura, "JSON Web Key (JWK) Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", draft-ietf-jose-jwk-thumbprint (work in Thumbprint", draft-ietf-jose-jwk-thumbprint (work in
progress), July 2015, <http://tools.ietf.org/html/ progress), July 2015, <http://tools.ietf.org/html/
draft-ietf-jose-jwk-thumbprint-08>. draft-ietf-jose-jwk-thumbprint-08>.
[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.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank Brian Campbell, James Manger, Justin The authors wish to thank Brian Campbell, Kepeng Li, James Manger,
Richer, and Nat Sakimura for their reviews of the specification. Justin Richer, and Nat Sakimura for their reviews of the
specification.
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 ]]
-05
o Addressed review comments by Kepeng Li.
-04 -04
o Allowed the use of "jwk" for symmetric keys when the JWT is o Allowed the use of "jwk" for symmetric keys when the JWT is
encrypted. encrypted.
o Added the "jku" (JWK Set URL) member. o Added the "jku" (JWK Set URL) member.
o Added privacy considerations. o Added privacy considerations.
o Reordered sections so that the "cnf" (confirmation) claim is o Reordered sections so that the "cnf" (confirmation) claim is
 End of changes. 14 change blocks. 
23 lines changed or deleted 34 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/