draft-ietf-oauth-proof-of-possession-01.txt		draft-ietf-oauth-proof-of-possession-02.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: August 1, 2015 Ping Identity		Expires: September 10, 2015 Ping Identity
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	January 28, 2015		March 9, 2015
	Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)		Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
	draft-ietf-oauth-proof-of-possession-01		draft-ietf-oauth-proof-of-possession-02
	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. This property is also
	sometimes described as the presenter being a holder-of-key.		sometimes described as the presenter being a holder-of-key.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 1, 2015.		This Internet-Draft will expire on September 10, 2015.
	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
	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
	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 . . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Proof-Of-Possession Representation . . . . . . . . . . . . . . 4		3. Proof-Of-Possession Representation . . . . . . . . . . . . . . 4
	3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . . 4		3.1. Proof-of-Possession of an Asymmetric Key . . . . . . . . . 5
	3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . . 5		3.2. Proof-of-Possession of a Symmetric Key . . . . . . . . . . 5
	3.3. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Proof-of-Possession Using a Key ID . . . . . . . . . . . . 6
	3.4. Specifics Intentionally Not Specified . . . . . . . . . . 6		3.4. Confirmation . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5.1. JSON Web Token Claims Registration . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8		5.1. JSON Web Token Claims Registration . . . . . . . . . . . . 9
	5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 8		5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 9
	5.2.1. Registration Template . . . . . . . . . . . . . . . . 9		5.2. JWT Confirmation Methods Registry . . . . . . . . . . . . 10
	5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 9		5.2.1. Registration Template . . . . . . . . . . . . . . . . 10
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. Informative References . . . . . . . . . . . . . . . . . . 10		6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10		6.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 10		Appendix B. Document History . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	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) [JWT] that the presenter of the JWT possesses a		Token (JWT) [JWT] that the presenter of the JWT 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. This property is		proof-of-possession of the key by the presenter. This property is
	also sometimes described as the presenter being a holder-of-key.		also sometimes described as the presenter being a holder-of-key.
	[[ Editorial Note: This paragraph needs to be updated to provide more		Envision the following two use cases. The first use case describes
	context and possibly also to describe the use of asymmetric keys		the use of a symmetric proof-of-possession key and the second use
	instead. It's not clear that the symmetric case is as useful or		case uses an asymmetric proof-of-possession key.
	valuable, and it is certainly more complicated.]] Envision the
	following use case: An OAuth 2.0 authorization server generates a JWT		An OAuth 2.0 authorization server generates a JWT and places an
	and places an encrypted symmetric key inside the newly introduced		encrypted symmetric key inside the newly introduced confirmation
	confirmation claim. This symmetric key is encrypted with a key known		claim. This symmetric key is encrypted with a key known only to the
	only to the authorization server and the recipient. The JWT is then		authorization server and the recipient. The entire JWT is then
	sent to the presenter. Since the presenter is unable to obtain the		integrity protected by the issuer (the authorization server). The
	encrypted symmetric key, the authorization server conveys that		JWT is then sent to the presenter. Since the presenter is unable to
	symmetric key separately to the presenter. Now, the presenter is in		obtain the encrypted symmetric key from the JWT itself, the
	possession of the symmetric key as well as the JWT (which includes		authorization server conveys that symmetric key separately to the
	the confirmation claim member). When the presenter needs to utilize		presenter. Now, the presenter is in possession of the symmetric key
	the JWT to at recipient, it also needs to demonstrate possession of		as well as the JWT (which includes the confirmation claim member).
	the symmetric key; the presenter, for example, uses the symmetric key		When the presenter needs to present the JWT to the recipient, it also
	in a challenge/response protocol with the recipient. The recipient		needs to demonstrate possession of the symmetric key; the presenter,
	is able to verify that it is interacting with the genuine presenter		for example, uses the symmetric key in a challenge/response protocol
	by decrypting the JWK contained inside the confirmation claim of the		with the recipient. The recipient is then able to verify that it is
	JWT. By doing this the recipient obtains the symmetric key, which it		interacting with the genuine presenter by decrypting the JWK
	then uses to verify cryptographically protected messages exchanged		contained inside the confirmation claim of the JWT. By doing this,
	with the presenter.		the recipient obtains the symmetric key, which it then uses to verify
			cryptographically protected messages exchanged with the presenter.
			This symmetric key mechanism described above is conceptually similar
			to the use of Kerberos tickets.
			In the second case, consider a presenter that generates a public/
			private key pair. It then sends the public key to an OAuth 2.0
			authorization server (the issuer), which creates a JWT and places a
			public key (or an identifier for it) inside the newly introduced
			confirmation claim. The entire JWT is integrity protected using a
			digital signature to protect it against modifications. The JWT is
			then sent to the presenter. When the presenter needs to present the
			JWT to the recipient, it also needs to demonstrate possession of the
			private key. The presenter, for example, uses the private key in a
			TLS exchange with the recipient. The recipient is able to verify
			that it is interacting with the genuine presenter by extracting the
			public key from the confirmation claim of the JWT (after verifying
			the digital signature of the JWT) and utilizing it with the private
			key in the TLS exchange. The asymmetric key mechanism described
			above is conceptually similar to a certificate.
			In both cases the JWT may contain other claims that are needed by the
			application.
	1.1. Notational Conventions		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in RFC
			2119 [RFC2119].
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.		are case sensitive.
	2. Terminology		2. Terminology
	This specification uses terms defined in the JSON Web Token (JWT)		This specification uses terms defined in the JSON Web Token (JWT)
	[JWT], JSON Web Key (JWK) [JWK], and JSON Web Encryption (JWE) [JWE]		[JWT], JSON Web Key (JWK) [JWK], and JSON Web Encryption (JWE) [JWE]
	specifications.		specifications.
	These terms are defined by this specification:		These terms are defined by this specification:
			Issuer
			Party that creates the JWT and binds the proof-of-possession key
			to it.
	Presenter		Presenter
	Party that possesses the key identified by the JWT.		Party that proves possession of a private key (for asymmetric key
			cryptography) or secret key (for symmetric key cryptography) to a
			recipient. The presenter may be the issuer or a party different
			from the issuer.
			Recipient
			Party that receives the JWT containing the proof-of-possession key
			information from the presenter.
	3. Proof-Of-Possession Representation		3. Proof-Of-Possession Representation
	The presenter of a JWT declares that it possesses a particular key		The presenter of a JWT declares that it 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 issuer by including a "cnf"		possession of the key by the presenter by including a "cnf"
	(confirmation) claim in the JWT whose value is a JSON object, with		(confirmation) claim in the JWT whose value is a JSON object, with
	the JSON object containing a "jwk" (JSON Web Key) member identifying		the JSON object containing a "jwk" (JSON Web Key) or "kid" (key ID)
	the key.		member identifying the key.
	The presenter can be identified in one of two ways by the JWT,		The presenter can be identified in one of two 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 the subject identified by the		"sub" (subject) claim, the presenter is the subject identified by the
	JWT. (In some applications, the subject identifier will be relative		JWT. (In some applications, the subject identifier will be relative
	to the issuer identified by the "iss" (issuer) claim.) If the JWT		to the issuer identified by the "iss" (issuer) claim.) If the JWT
	contains no "sub" (subject) claim, the presenter is the issuer		contains no "sub" (subject) claim, the presenter is the issuer
	identified by the JWT using the "iss" (issuer) claim. The case in		identified by the JWT using the "iss" (issuer) claim. The case in
	which the presenter is the subject of the JWT is analogous to SAML		which the presenter is the subject of the JWT is analogous to SAML
	2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one		2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one
	of the "sub" and "iss" claims MUST be present in the JWT, and in some		of the "sub" and "iss" claims MUST be present in the JWT, and in some
	use cases, both MUST be present.		use cases, both MUST be present.
	3.1. Proof-of-Possession of an Asymmetric Key		3.1. Proof-of-Possession of an Asymmetric Key
	When the key held by the issuer is an asymmetric private key, the		When the key held by the presenter is an asymmetric private key, the
	value of the "jwk" member is a JSON Web Key (JWK) [JWK] representing		value of the "jwk" member is a JSON Web Key (JWK) [JWK] representing
	the corresponding asymmetric public key. The following example		the 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":"xas.example.com",		"iss": "https://server.example.com",
	"aud":"http://auth.example.com",		"aud": "https://client.example.org",
	"exp":"1361398824",		"exp": "1361398824",
	"nbf":"1360189224",		"nbf": "1360189224",
	"cnf":{		"cnf":{
	"jwk":{		"jwk":{
	"kty":"EC",		"kty": "EC",
	"use":"sig",		"use": "sig",
	"crv":"P-256",		"crv": "P-256",
	"x":"18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",		"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
	"y":"-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"		"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
	}		}
	}		}
	}		}
	The JWK MUST contain the required key members for a JWK of that key		The JWK MUST contain the required key members for a JWK of that key
	type and MAY contain other JWK members, including the "kid" (key ID)		type and MAY contain other JWK members, including the "kid" (key ID)
	member.		member.
	3.2. Proof-of-Possession of a Symmetric Key		3.2. Proof-of-Possession of a Symmetric Key
	When the key held by the issuer is a symmetric key, the value of the		When the key held by the presenter is a symmetric key, the value of
	"jwk" member is an encrypted JSON Web Key (JWK) [JWK] encrypted to a		the "jwk" member is an encrypted JSON Web Key (JWK) [JWK] encrypted
	key known to the recipient using the JWE Compact Serialization		to a key known to the recipient using the JWE Compact Serialization
	containing the symmetric key. The rules for encrypting a JWK are		containing the symmetric key. The rules for encrypting a JWK are
	found in Section 6 of the JSON Web Key [JWK] specification.		found in Section 6 of the JSON Web Key [JWK] specification.
	The following example illustrates a symmetric key that could		The following example illustrates a symmetric key that could
	subsequently be encrypted for use in the "jwk" member:		subsequently be encrypted for use in the "jwk" member:
	{		{
	"kty":"oct",		"kty": "oct",
	"alg":"HS256",		"alg": "HS256",
	"k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"		"k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
	}		}
	The UTF-8 [RFC3629] encoding of this JWK would be used as the JWE		The UTF-8 [RFC3629] encoding of this JWK would be used as the JWE
	Plaintext when encrypting the key.		Plaintext when encrypting the key.
	The following example is a JWE Header that could be used when		The following example is a JWE Header that could be used when
	encrypting this key:		encrypting this key:
	{		{
	"alg":"RSA1_5",		"alg": "RSA1_5",
	"enc":"A128CBC-HS256",		"enc": "A128CBC-HS256",
	"cty":"jwk+json"		"cty": "jwk+json"
	}		}
	The following example JWT Claims Set of a JWT illustrates the use of		The following example JWT Claims Set of a JWT illustrates the use of
	an encrypted symmetric key as the "jwk" claim value:		an encrypted symmetric key as the "jwk" claim value:
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"sub": "24400320",		"sub": "24400320",
	"aud": "s6BhdRkqt3",		"aud": "s6BhdRkqt3",
	"nonce": "n-0S6_WzA2Mj",		"nonce": "n-0S6_WzA2Mj",
	skipping to change at page 6, line 4		skipping to change at page 6, line 38
	"sub": "24400320",		"sub": "24400320",
	"aud": "s6BhdRkqt3",		"aud": "s6BhdRkqt3",
	"nonce": "n-0S6_WzA2Mj",		"nonce": "n-0S6_WzA2Mj",
	"exp": 1311281970,		"exp": 1311281970,
	"iat": 1311280970,		"iat": 1311280970,
	"cnf":{		"cnf":{
	"jwk":		"jwk":
	"eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5Ijoi		"eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5Ijoi
	andrK2pzb24ifQ. ... (remainder of JWE omitted for brevity)"		andrK2pzb24ifQ. ... (remainder of JWE omitted for brevity)"
	}		}
	}		}
	Note that the case in which the "jwk" claim contains an unencoded JWK		Note that the case in which the "jwk" claim contains an unencoded JWK
	value and the case in which it contains an encrypted JWK value can be		value and the case in which it contains an encrypted JWK value can be
	distinguished by the type of the member value. In the first case,		distinguished by the type of the member value. In the first case,
	the value is a JSON object containing the JWK and in the second case,		the value is a JSON object containing the JWK and in the second case,
	the value is a string containing the JWE JSON Serialization of the		the value is a string containing the JWE JSON Serialization of the
	encrypted JWK representation.		encrypted JWK representation.
	3.3. Confirmation		3.3. Proof-of-Possession Using a Key ID
			The proof-of-possession key can also be identified by the use of a
			Key ID instead of communicating the actual key, provided the
			recipient is able to obtain the identified key using the Key ID. In
			this case, the presenter of a JWT declares that it possesses a
			particular key and that the recipient can cryptographically confirm
			proof-of-possession of the key by the presenter by including a "cnf"
			(confirmation) claim in the JWT whose value is a JSON object, with
			the JSON object containing a "kid" (key ID) member identifying the
			key.
			The following example demonstrates such a declaration in the JWT
			Claims Set of a JWT:
			{
			"iss": "https://server.example.com",
			"aud": "https://client.example.org",
			"exp": "1361398824",
			"nbf": "1360189224",
			"cnf":{
			"kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad"
			}
			}
			3.4. Confirmation
	The "cnf" (confirmation) claim is used in the JWT to contain the		The "cnf" (confirmation) claim is used in the JWT to contain the
	"jwk" member because a proof-of-possession key may not be the only		"jwk" or "kid" member because a proof-of-possession key may not be
	means of confirming the authenticity of the token. This is analogous		the only means of confirming the authenticity of the token. This is
	to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element,		analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
	in which a number of different subject confirmation methods can be		SubjectConfirmation element, in which a number of different subject
	included, including proof-of-possession key information. When a		confirmation methods can be included, including proof-of-possession
	recipient receives a "cnf" claim with a member that it does not		key information. When a recipient receives a "cnf" claim with a
	understand, it MUST ignore that member.		member that it does not understand, it MUST ignore that member.
	This specification defines a registry for these members in		This specification defines a registry for these members in
	Section 5.2 and registers the "jwk" member within the registry.		Section 5.2 and registers the "jwk" and "kid" members within the
			registry.
	3.4. Specifics Intentionally Not Specified		3.5. Specifics Intentionally Not Specified
	Proof-of-possession is typically demonstrated by having the issuer		Proof-of-possession is typically demonstrated by having the presenter
	sign a value determined by the recipient using the key possessed by		sign a value determined by the recipient using the key possessed by
	the issuer. This value is sometimes called a "nonce" or a		the presenter. This value is sometimes called a "nonce" or a
	"challenge".		"challenge".
	The means of communicating the nonce and the nature of its contents		The means of communicating the nonce and the nature of its contents
	are intentionally not described in this specification, as different		are intentionally not described in this specification, as different
	protocols will communicate this information in different ways.		protocols will communicate this information in different ways.
	Likewise, the means of communicating the signed nonce is also not		Likewise, the means of communicating the signed nonce is also not
	specified, as this is also protocol-specific.		specified, as this is also protocol-specific.
	Note that another means of proving possession of the key when it is a		Note that another means of proving possession of the key when it is a
	symmetric key is to encrypt the key to the recipient. The means of		symmetric key is to encrypt the key to the recipient. The means of
	skipping to change at page 7, line 40		skipping to change at page 9, line 4
	since demonstration the possession of the key associated with the		since demonstration the possession of the key associated with the
	"cnf" claim is not covered by this specification. For more details,		"cnf" claim is not covered by this specification. For more details,
	please consult [I-D.ietf-oauth-pop-architecture].		please consult [I-D.ietf-oauth-pop-architecture].
	5. IANA Considerations		5. IANA Considerations
	The following registration procedure is used for all the registries		The following registration procedure is used for all the registries
	established by this specification.		established by this specification.
	Values are registered with a Specification Required [RFC5226] after a		Values are registered with a Specification Required [RFC5226] after a
	two-week review period on the [TBD]@ietf.org mailing list, on the		three-week review period on the [TBD]@ietf.org mailing list, on the
	advice of one or more Designated Experts. However, to allow for the		advice of one or more Designated Experts. However, to allow for the
	allocation of values prior to publication, the Designated Expert(s)		allocation of values prior to publication, the Designated Expert(s)
	may approve registration once they are satisfied that such a		may approve registration once they are satisfied that such a
	specification will be published.		specification will be published.
	Registration requests must be sent to the [TBD]@ietf.org mailing list		Registration requests must be sent to the [TBD]@ietf.org mailing list
	for review and comment, with an appropriate subject (e.g., "Request		for review and comment, with an appropriate subject (e.g., "Request
	for access token type: example"). [[ Note to the RFC Editor: The name		for access token type: example"). [[ Note to the RFC Editor: The name
	of the mailing list should be determined in consultation with the		of the mailing list should be determined in consultation with the
	IESG and IANA. Suggested name: jwt-reg-review. ]]		IESG and IANA. Suggested name: oauth-pop-reg-review@ietf.org. ]]
	Within the review period, the Designated Expert(s) will either		Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision		approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation		to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request		and, if applicable, suggestions as to how to make the request
	successful. Registration requests that are undetermined for a period		successful. Registration requests that are undetermined for a period
	longer than 21 days can be brought to the IESG's attention (using the		longer than 21 days can be brought to the IESG's attention (using the
	iesg@iesg.org mailing list) for resolution.		iesg@ietf.org mailing list) for resolution.
	Criteria that should be applied by the Designated Expert(s) includes		Criteria that should be applied by the Designated Expert(s) includes
	determining whether the proposed registration duplicates existing		determining whether the proposed registration duplicates existing
	functionality, determining whether it is likely to be of general		functionality, determining whether it is likely to be of general
	applicability or whether it is useful only for a single application,		applicability or whether it is useful only for a single application,
	and whether the registration makes sense.		and whether the registration makes sense.
	IANA must only accept registry updates from the Designated Expert(s)		IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing		and should direct all requests for registration to the review mailing
	list.		list.
	skipping to change at page 8, line 40		skipping to change at page 10, line 6
	5.1. JSON Web Token Claims Registration		5.1. JSON Web Token Claims Registration
	This specification registers the "cnf" claim in the IANA JSON Web		This specification registers the "cnf" claim in the IANA JSON Web
	Token Claims registry defined in [JWT].		Token Claims registry defined in [JWT].
	5.1.1. Registry Contents		5.1.1. Registry Contents
	o Claim Name: "cnf"		o Claim Name: "cnf"
	o Claim Description: Confirmation		o Claim Description: Confirmation
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.3 of this document		o Specification Document(s): Section 3.4 of this document
	5.2. JWT Confirmation Methods Registry		5.2. JWT Confirmation Methods Registry
	This specification establishes the IANA JWT Confirmation Methods		This specification establishes the IANA JWT Confirmation Methods
	registry for JWT "cnf" member values. The registry records the		registry for JWT "cnf" member values. The registry records the
	confirmation method member and a reference to the specification that		confirmation method member and a reference to the specification that
	defines it.		defines it.
	5.2.1. Registration Template		5.2.1. Registration Template
	skipping to change at page 9, line 38		skipping to change at page 10, line 48
	preferably including URI(s) that can be used to retrieve copies of		preferably including URI(s) that can be used to retrieve copies of
	the document(s). An indication of the relevant sections may also		the document(s). An indication of the relevant sections may also
	be included but is not required.		be included but is not required.
	5.2.2. Initial Registry Contents		5.2.2. Initial Registry Contents
	o Confirmation Method Value: "jwk"		o Confirmation Method Value: "jwk"
	o Confirmation Method Description: JSON Web Key or Encrypted JSON		o Confirmation Method Description: JSON Web Key or Encrypted JSON
	Web Key		Web Key
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3 of [[ this document ]]		o Specification Document(s): Section 3.1 of [[ this document ]]
			o Confirmation Method Value: "kid"
			o Confirmation Method Description: Key Identifier
			o Change Controller: IESG
			o Specification Document(s): Section 3.3 of [[ this document ]]
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",		[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
	draft-ietf-jose-json-web-encryption (work in progress),		draft-ietf-jose-json-web-encryption (work in progress),
	January 2015.		January 2015.
	[JWK] Jones, M., "JSON Web Key (JWK)",		[JWK] Jones, M., "JSON Web Key (JWK)",
	skipping to change at page 10, line 22		skipping to change at page 11, line 38
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	6.2. Informative References		6.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., ietf@justin.richer.org, i., Mills, W., Mishra,
	Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security		P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession
	Architecture", draft-ietf-oauth-pop-architecture-00 (work		(PoP) Security Architecture",
	in progress), July 2014.		draft-ietf-oauth-pop-architecture-01 (work in progress),
			March 2015.
	[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.
	Appendix A. Open Issues		Appendix A. Acknowledgements
	In some conversations, we have said that it is the issuer of the JWT
	that possesses the key, and in some conversations, we have said that
	it is the presenter of the JWT that possesses the key. Which
	description should we use?
	Appendix B. Acknowledgements
	The authors wish to thank James Manger for his review of the		The authors wish to thank James Manger for his review of the
	specification.		specification.
	Appendix C. 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 ]]
			-02
			o Defined the terms Issuer, Presenter, and Recipient and updated
			their usage within the document.
			o Added a description of a use case using an asymmetric proof-of-
			possession key to the introduction.
			o Added the "kid" (key ID) confirmation method.
			o These changes address the open issues identified in the previous
			draft.
	-01		-01
	o Updated references.		o Updated references.
	-00		-00
	o Created the initial working group draft from		o Created the initial working group draft from
	draft-jones-oauth-proof-of-possession-02.		draft-jones-oauth-proof-of-possession-02.
	Authors' Addresses		Authors' Addresses
	Michael B. Jones		Michael B. Jones
End of changes. 36 change blocks.
	100 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/