< draft-jones-ace-cwt-proof-of-possession-00.txt		draft-jones-ace-cwt-proof-of-possession-01.txt >
	ACE Working Group M. Jones		ACE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track April 20, 2017		Intended status: Standards Track L. Seitz
	Expires: October 22, 2017		Expires: January 1, 2018 RISE SICS
			G. Selander
			Ericsson AB
			E. Wahlstroem
			S. Erdtman
			Spotify AB
			H. Tschofenig
			ARM Ltd.
			June 30, 2017
	Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)		Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
	draft-jones-ace-cwt-proof-of-possession-00		draft-jones-ace-cwt-proof-of-possession-01
	Abstract		Abstract
	This specification describes how to declare in a CBOR Web Token (CWT)		This specification describes how to declare in a CBOR Web Token (CWT)
	that the presenter of the CWT possesses a particular proof-of-		that the presenter of the CWT possesses a particular proof-of-
	possession key and how the recipient can cryptographically confirm		possession key. Being able to prove possession of a key is also
	proof of possession of the key by the presenter. Being able to prove		sometimes described as the presenter being a holder-of-key. This
	possession of a key is also sometimes described as the presenter		specification provides equivalent functionality to "Proof-of-
	being a holder-of-key. This specification is a profile of "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but		Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but
	using CBOR and CWTs rather than JSON and JWTs.		using CBOR and CWTs rather than JSON and JWTs.
	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 October 22, 2017.		This Internet-Draft will expire on January 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 27 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Representations for Proof-of-Possession Keys . . . . . . . . 3		3. Representations for Proof-of-Possession Keys . . . . . . . . 3
	3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4		3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4
	3.2. Representation of an Asymmetric Proof-of-Possession Key . 4		3.2. Representation of an Asymmetric Proof-of-Possession Key . 5
	3.3. Representation of an Encrypted Symmetric Proof-of-		3.3. Representation of an Encrypted Symmetric Proof-of-
	Possession Key . . . . . . . . . . . . . . . . . . . . . 5		Possession Key . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Representation of a Key ID for a Proof-of-Possession Key 6		3.4. Representation of a Key ID for a Proof-of-Possession Key 6
	3.5. Specifics Intentionally Not Specified . . . . . . . . . . 6		3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6.1. CBOR Web Token Claims Registration . . . . . . . . . . . 8		6.1. CBOR Web Token Claims Registration . . . . . . . . . . . 9
	6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 9		6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 9
	6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 9		6.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 9
	6.2.1. Registration Template . . . . . . . . . . . . . . . . 9		6.2.1. Registration Template . . . . . . . . . . . . . . . . 9
	6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10		6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
	Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Document History . . . . . . . . . . . . . . . . . . . . . . . . 12		Document History . . . . . . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	This specification describes how a CBOR Web Token [CWT] can declare		This specification describes how a CBOR Web Token [CWT] can declare
	that the presenter of the CWT possesses a particular proof-of-		that the presenter of the CWT possesses a particular proof-of-
	possession (PoP) key and how the recipient can cryptographically		possession (PoP) key. Proof of possession of a key is also sometimes
	confirm proof of possession of the key by the presenter. Proof of		described as the presenter being a holder-of-key. This specification
	possession of a key is also sometimes described as the presenter		provides equivalent functionality to "Proof-of-Possession Key
	being a holder-of-key. This specification is a profile of "Proof-of-		Semantics for JSON Web Tokens (JWTs)" [RFC7800], but using CBOR
	Possession Key Semantics for JSON Web Tokens (JWTs)" [RFC7800], but		[RFC7049] and CWTs [CWT] rather than JSON [RFC7159] and JWTs [JWT].
	using CBOR [RFC7049] and CWTs [CWT] rather than JSON [RFC7159] and
	JWTs [JWT].
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[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.
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 45 ¶
	Recipient		Recipient
	Party that receives the CWT containing the proof-of-possession key		Party that receives the CWT containing the proof-of-possession key
	information from the presenter.		information from the presenter.
	3. Representations for Proof-of-Possession Keys		3. Representations for Proof-of-Possession Keys
	By including a "cnf" (confirmation) claim in a CWT, the issuer of the		By including a "cnf" (confirmation) claim in a CWT, the issuer of the
	CWT declares that the presenter possesses a particular key and that		CWT declares that the presenter possesses a particular key and that
	the recipient can cryptographically confirm that the presenter has		the recipient can cryptographically confirm that the presenter has
	possession of that key. The value of the "cnf" claim is a JSON		possession of that key. The value of the "cnf" claim is a CBOR map
	object and the members of that object identify the proof-of-		and the members of that map identify the proof-of-possession key.
	possession key.
	The presenter can be identified in one of several ways by the CWT		The presenter can be identified in one of several ways by the CWT
	depending upon the application requirements. If the CWT contains a		depending upon the application requirements. If the CWT contains a
	"sub" (subject) claim [CWT], the presenter is normally the subject		"sub" (subject) claim [CWT], the presenter is normally the subject
	identified by the CWT. (In some applications, the subject identifier		identified by the CWT. (In some applications, the subject identifier
	will be relative to the issuer identified by the "iss" (issuer) claim		will be relative to the issuer identified by the "iss" (issuer) claim
	[CWT].) If the CWT contains no "sub" claim, the presenter is		[CWT].) If the CWT contains no "sub" claim, the presenter is
	normally the issuer identified by the CWT using the "iss" claim. The		normally the issuer identified by the CWT using the "iss" claim. The
	case in which the presenter is the subject of the CWT is analogous to		case in which the presenter is the subject of the CWT is analogous to
	Security Assertion Markup Language (SAML) 2.0		Security Assertion Markup Language (SAML) 2.0
	[OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of		[OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of
	the "sub" and "iss" claims MUST be present in the CWT. Some use		the "sub" and "iss" claims is typically present in the CWT and some
	cases may require that both be present.		use cases may require that both be present.
	3.1. Confirmation Claim		3.1. Confirmation Claim
	The "cnf" claim is used in the CWT to contain members used to		The "cnf" claim is used in the CWT to contain members used to
	identify the proof-of-possession key. Other members of the "cnf"		identify the proof-of-possession key. Other members of the "cnf" map
	object may be defined because a proof-of-possession key may not be		may be defined because a proof-of-possession key may not be the only
	the only means of confirming the authenticity of the token. This is		means of confirming the authenticity of the token. This is analogous
	analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]		to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation element
	SubjectConfirmation element in which a number of different subject		in which a number of different subject confirmation methods can be
	confirmation methods can be included (including proof-of-possession		included (including proof-of-possession key information).
	key information).
	The set of confirmation members that a CWT must contain to be		The set of confirmation members that a CWT must contain to be
	considered valid is context dependent and is outside the scope of		considered valid is context dependent and is outside the scope of
	this specification. Specific applications of CWTs will require		this specification. Specific applications of CWTs will require
	implementations to understand and process some confirmation members		implementations to understand and process some confirmation members
	in particular ways. However, in the absence of such requirements,		in particular ways. However, in the absence of such requirements,
	all confirmation members that are not understood by implementations		all confirmation members that are not understood by implementations
	MUST be ignored.		MUST be ignored.
	This specification establishes the IANA "CWT Confirmation Methods"		This specification establishes the IANA "CWT Confirmation Methods"
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 9 ¶
	additional proof-of-possession key information. These claims could		additional proof-of-possession key information. These claims could
	use the same syntax and semantics as the "cnf" claim. Those claims		use the same syntax and semantics as the "cnf" claim. Those claims
	would be defined by applications or other specifications and could be		would be defined by applications or other specifications and could be
	registered in the IANA "CBOR Web Token Claims" registry		registered in the IANA "CBOR Web Token Claims" registry
	[IANA.CWT.Claims].		[IANA.CWT.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
	"COSE_Key" member is a COSE_Key [I-D.ietf-cose-msg] representing the		"COSE_Key" member is a COSE_Key [I-D.ietf-cose-msg] representing the
	corresponding asymmetric public key. The following example		corresponding asymmetric public key. The following example (using
	demonstrates such a declaration in the CWT Claims Set of a CWT:		JSON notation) demonstrates such a declaration in the CWT Claims Set
			of a CWT:
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"aud": "https://client.example.org",		"aud": "https://client.example.org",
	"exp": 1361398824,		"exp": 1361398824,
	"cnf":{		"cnf":{
	"COSE_Key":{		"COSE_Key":{
	"kty": "EC",		"kty": "EC",
	"crv": "P-256",		"crv": "P-256",
	"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",		"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 44 ¶
	explained in [CWT]. If the CWT is not encrypted, the symmetric key		explained in [CWT]. If the CWT is not encrypted, the symmetric key
	MUST be encrypted as described below.		MUST be encrypted as described below.
	3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key		3.3. Representation of an Encrypted Symmetric Proof-of-Possession Key
	When the key held by the presenter is a symmetric key, the		When the key held by the presenter is a symmetric key, the
	"Encrypted_COSE_Key" member is an encrypted COSE_Key		"Encrypted_COSE_Key" member is an encrypted COSE_Key
	[I-D.ietf-cose-msg] representing the symmetric key encrypted to a key		[I-D.ietf-cose-msg] representing the symmetric key encrypted to a key
	known to the recipient using COSE_Encrypt or COSE_Encrypt0.		known to the recipient using COSE_Encrypt or COSE_Encrypt0.
	The following example illustrates a symmetric key that could		The following example (using JSON notation) illustrates a symmetric
	subsequently be encrypted for use in the "Encrypted_COSE_Key" member:		key that could subsequently be encrypted for use in the
			"Encrypted_COSE_Key" member:
	{		{
	"kty": "oct",		"kty": "oct",
	"alg": "HS256",		"alg": "HS256",
	"k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"		"k": "ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
	}		}
	The COSE_Key representation is used as the plaintext when encrypting		The COSE_Key representation is used as the plaintext when encrypting
	the key. The COSE_Key could, for instance, be encrypted using a		the key. The COSE_Key could, for instance, be encrypted using a
	COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm.		COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm.
	The following example CWT Claims Set of a CWT illustrates the use of		The following example CWT Claims Set of a CWT (using JSON notation)
	an encrypted symmetric key as the "Encrypted_COSE_Key" member value:		illustrates the use of an encrypted symmetric key as the
			"Encrypted_COSE_Key" member value:
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"sub": "24400320",		"sub": "24400320",
	"aud": "s6BhdRkqt3",		"aud": "s6BhdRkqt3",
	"exp": 1311281970,		"exp": 1311281970,
	"iat": 1311280970,		"iat": 1311280970,
	"cnf":{		"cnf":{
	"Encrypted_COSE_Key":		"Encrypted_COSE_Key":
	"(TBD)"		"(TBD)"
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 33 ¶
	}		}
	3.4. Representation of a Key ID for a Proof-of-Possession Key		3.4. Representation of a Key ID for a Proof-of-Possession Key
	The proof-of-possession key can also be identified by the use of a		The proof-of-possession key can also be identified by the use of a
	Key ID instead of communicating the actual key, provided the		Key ID instead of communicating the actual key, provided the
	recipient is able to obtain the identified key using the Key ID. In		recipient is able to obtain the identified key using the Key ID. In
	this case, the issuer of a CWT declares that the presenter possesses		this case, the issuer of a CWT declares that the presenter possesses
	a particular key and that the recipient can cryptographically confirm		a 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"
	claim in the CWT whose value is a JSON object with the JSON object		claim in the CWT whose value is a CBOR map with the CBOR map
	containing a "kid" member identifying the key.		containing a "kid" member identifying the key.
	The following example demonstrates such a declaration in the CWT		The following example (using JSON notation) demonstrates such a
	Claims Set of a CWT:		declaration in the CWT Claims Set of a CWT:
	{		{
	"iss": "https://server.example.com",		"iss": "https://server.example.com",
	"aud": "https://client.example.org",		"aud": "https://client.example.org",
	"exp": 1361398824,		"exp": 1361398824,
	"cnf":{		"cnf":{
	"kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad"		"kid": "dfd1aa97-6d8d-4575-a0fe-34b96de2bfad"
	}		}
	}		}
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 17 ¶
	6.1. CBOR Web Token Claims Registration		6.1. CBOR Web Token Claims Registration
	This specification registers the "cnf" claim in the IANA "CBOR Web		This specification registers the "cnf" claim in the IANA "CBOR Web
	Token Claims" registry [IANA.CWT.Claims] established by [CWT].		Token Claims" registry [IANA.CWT.Claims] established by [CWT].
	6.1.1. Registry Contents		6.1.1. Registry Contents
	o Claim Name: "cnf"		o Claim Name: "cnf"
	o Claim Description: Confirmation		o Claim Description: Confirmation
	o JWT Claim Name: "cnf"		o JWT Claim Name: "cnf"
	o CBOR Key Value: TBD (maybe 8)		o Claim Key: TBD (maybe 8)
	o CBOR Major Type: 5		o Claim Value Type(s): map
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.1 of [[ this document ]]		o Specification Document(s): Section 3.1 of [[ this document ]]
	6.2. CWT Confirmation Methods Registry		6.2. CWT Confirmation Methods Registry
	This specification establishes the IANA "CWT Confirmation Methods"		This specification establishes the IANA "CWT Confirmation Methods"
	registry for CWT "cnf" member values. The registry records the		registry for CWT "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.
	6.2.1. Registration Template		6.2.1. Registration Template
	Confirmation Method Name:		Confirmation Method Name:
	The human-readable name requested (e.g., "kid").		The human-readable name requested (e.g., "kid").
	Confirmation Method Description:		Confirmation Method Description:
	Brief description of the confirmation method (e.g., "Key		Brief description of the confirmation method (e.g., "Key
	Identifier").		Identifier").
	JWT Conformation Method Name:		JWT Confirmation Method Name:
	Claim Name of the equivalent JWT confirmation method value, as		Claim Name of the equivalent JWT confirmation method value, as
	registered in [IANA.JWT.Claims]. CWT claims should normally have		registered in [IANA.JWT.Claims]. CWT claims should normally have
	a corresponding JWT claim. If a corresponding JWT claim would not		a corresponding JWT claim. If a corresponding JWT claim would not
	make sense, the Designated Experts can choose to accept		make sense, the Designated Experts can choose to accept
	registrations for which the JWT Claim Name is listed as "N/A".		registrations for which the JWT Claim Name is listed as "N/A".
	CBOR Key Value:		Confirmation Key:
	Key value for the confirmation method. The key value MUST be an		CBOR map key value for the confirmation method.
	integer in the range of 1 to 65536.
	CBOR Major Type:		Confirmation Value Type(s):
	CBOR major type and, when applicable, minor type for the claim.		CBOR types that can be used for the confirmation method value.
	Change Controller:		Change Controller:
	For Standards Track RFCs, list the "IESG". For others, give the		For Standards Track RFCs, list the "IESG". For others, give the
	name of the responsible party. Other details (e.g., postal		name of the responsible party. Other details (e.g., postal
	address, email address, home page URI) may also be included.		address, email address, home page URI) may also be included.
	Specification Document(s):		Specification Document(s):
	Reference to the document or documents that specify the parameter,		Reference to the document or documents that specify the parameter,
	preferably including URIs that can be used to retrieve copies of		preferably including URIs that can be used to retrieve copies of
	the documents. An indication of the relevant sections may also be		the documents. An indication of the relevant sections may also be
	included but is not required.		included but is not required.
	6.2.2. Initial Registry Contents		6.2.2. Initial Registry Contents
	o Confirmation Method Name: "COSE_Key"		o Confirmation Method Name: "COSE_Key"
	o Confirmation Method Description: COSE_Key Representing Public Key		o Confirmation Method Description: COSE_Key Representing Public Key
	o JWT Confirmation Method Name: "jwk"		o JWT Confirmation Method Name: "jwk"
	o CBOR Key Value: 1		o Confirmation Key: 1
	o CBOR Major Type: 5		o Confirmation Value Type(s): map
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.2 of [[ this document ]]		o Specification Document(s): Section 3.2 of [[ this document ]]
	o Confirmation Method Name: "Encrypted_COSE_Key"		o Confirmation Method Name: "Encrypted_COSE_Key"
	o Confirmation Method Description: Encrypted COSE_Key		o Confirmation Method Description: Encrypted COSE_Key
	o JWT Confirmation Method Name: "jwe"		o JWT Confirmation Method Name: "jwe"
	o CBOR Key Value: 2		o Confirmation Key: 2
	o CBOR Major Type: 4 (with an optional 6 tag prefix)		o Confirmation Value Type(s): array (with an optional COSE_Encrypt
			or COSE_Encrypt0 tag)
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.3 of [[ this document ]]		o Specification Document(s): Section 3.3 of [[ this document ]]
	o Confirmation Method Name: "kid"		o Confirmation Method Name: "kid"
	o Confirmation Method Description: Key Identifier		o Confirmation Method Description: Key Identifier
	o JWT Confirmation Method Name: "kid"		o JWT Confirmation Method Name: "kid"
	o CBOR Key Value: 3		o Confirmation Key: 3
	o CBOR Major Type: 2		o Confirmation Value Type(s): binary string
	o Change Controller: IESG		o Change Controller: IESG
	o Specification Document(s): Section 3.4 of [[ this document ]]		o Specification Document(s): Section 3.4 of [[ this document ]]
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,		[CWT] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
	"CBOR Web Token (CWT)", Work in Progress, draft-ietf-ace-		"CBOR Web Token (CWT)", Work in Progress, draft-ietf-ace-
	cbor-web-token-04, April 2017,		cbor-web-token-06, June 2017,
	<https://tools.ietf.org/html/draft-ietf-ace-cbor-web-		<https://tools.ietf.org/html/draft-ietf-ace-cbor-web-
	token-04>.		token-06>.
	[I-D.ietf-cose-msg]		[I-D.ietf-cose-msg]
	Schaad, J., "CBOR Object Signing and Encryption (COSE)",		Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	draft-ietf-cose-msg-24 (work in progress), November 2016.		draft-ietf-cose-msg-24 (work in progress), November 2016.
	[IANA.CWT.Claims]		[IANA.CWT.Claims]
	IANA, "CBOR Web Token Claims",		IANA, "CBOR Web Token Claims",
	<http://www.iana.org/assignments/cwt>.		<http://www.iana.org/assignments/cwt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 11, line 20 ¶		skipping to change at page 11, line 28 ¶
	[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, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <http://www.rfc-editor.org/info/rfc3629>.		2003, <http://www.rfc-editor.org/info/rfc3629>.
	[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,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<http://www.rfc-editor.org/info/rfc3986>.
	[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", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 27 ¶
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <http://www.rfc-editor.org/info/rfc7159>.
	[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-		[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
	Possession Key Semantics for JSON Web Tokens (JWTs)",		Possession Key Semantics for JSON Web Tokens (JWTs)",
	RFC 7800, DOI 10.17487/RFC7800, April 2016,		RFC 7800, DOI 10.17487/RFC7800, April 2016,
	<http://www.rfc-editor.org/info/rfc7800>.		<http://www.rfc-editor.org/info/rfc7800>.
	Acknowledgements		Acknowledgements
	TBD		Thanks to the following people for their reviews of the
			specification: Michael Richardson and Jim Schaad.
	Open Issues		Open Issues
	o Convert the examples from JSON/JWT to CBOR/CWT.		o Convert the examples from JSON/JWT to CBOR/CWT.
	Document History		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 ]]
			-01
			o Tracked CBOR Web Token (CWT) Claims Registry updates.
			o Addressed review comments by Michael Richardson and Jim Schaad.
			o Added co-authors.
	-00		-00
	o Created the initial draft from RFC 7800.		o Created the initial draft from RFC 7800.
	Author's Address		Authors' Addresses
	Michael B. Jones		Michael B. Jones
	Microsoft		Microsoft
	Email: mbj@microsoft.com		Email: mbj@microsoft.com
	URI: http://self-issued.info/		URI: http://self-issued.info/
			Ludwig Seitz
			RISE SICS
			Scheelevaegen 17
			Lund 223 70
			Sweden
			Email: ludwig@ri.se
			Goeran Selander
			Ericsson AB
			Faeroegatan 6
			Kista 164 80
			Sweden
			Email: goran.selander@ericsson.com
			Erik Wahlstroem
			Sweden
			Email: erik@wahlstromstekniska.se
			Samuel Erdtman
			Spotify AB
			Birger Jarlsgatan 61, 4tr
			Stockholm 113 56
			Sweden
			Phone: +46702691499
			Email: erdtman@spotify.com
			Hannes Tschofenig
			ARM Ltd.
			Hall in Tirol 6060
			Austria
			Email: Hannes.Tschofenig@arm.com
End of changes. 32 change blocks.
	59 lines changed or deleted		76 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/