this.xml		that.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8747" consensus="true" c
	<rfc number="8747" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" c		ategory="std" docName="draft-ietf-ace-cwt-proof-of-possession-11" ipr="trust2009
	ategory="std"		02" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true
	docName="draft-ietf-ace-cwt-proof-of-possession-11" ipr="trust200902"		" tocDepth="4" symRefs="true" sortRefs="true" version="3">
	obsoletes="" updates="" submissionType="IETF" xml:lang="en"
	tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
	version="3">
	<!-- xml2rfc v2v3 conversion 2.38.0 -->		<!-- xml2rfc v2v3 conversion 2.38.0 -->
	<front>		<front>
	<title abbrev="Proof-of-Possession Key for CWTs">Proof-of-Possession Key		<title abbrev="Proof-of-Possession Key for CWTs">Proof-of-Possession Key
	Semantics for CBOR Web Tokens (CWTs)</title>		Semantics for CBOR Web Tokens (CWTs)</title>
	<seriesInfo name="RFC" value="8747"/>		<seriesInfo name="RFC" value="8747"/>
	<author fullname="Michael B. Jones" initials="M." surname="Jones">		<author fullname="Michael B. Jones" initials="M." surname="Jones">
	<organization>Microsoft</organization>		<organization>Microsoft</organization>
	<address>		<address>
	<email>mbj@microsoft.com</email>		<email>mbj@microsoft.com</email>
	<uri>https://self-issued.info/</uri>		<uri>https://self-issued.info/</uri>
	skipping to change at line 101 ¶		skipping to change at line 96 ¶
	This specification provides equivalent functionality to		This specification provides equivalent functionality to
	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" <xref targ et="RFC7800" format="default"/>		"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" <xref targ et="RFC7800" format="default"/>
	but using Concise Binary Object Representation (CBOR) <xref target="RFC70 49" format="default"/>		but using Concise Binary Object Representation (CBOR) <xref target="RFC70 49" format="default"/>
	and CWTs <xref target="RFC8392" format="default"/>		and CWTs <xref target="RFC8392" format="default"/>
	rather than JavaScript Object Notation (JSON) <xref target="RFC8259" form at="default"/>		rather than JavaScript Object Notation (JSON) <xref target="RFC8259" form at="default"/>
	and JSON Web Tokens (JWTs) <xref target="RFC7519" format="default"/>.		and JSON Web Tokens (JWTs) <xref target="RFC7519" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="Terminology" numbered="true" toc="default">		<section anchor="Terminology" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>		<t>
	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	to be interpreted as		to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	when, and only when, they appear in all capitals, as shown here.		when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	<t>		<t>
	skipping to change at line 148 ¶		skipping to change at line 143 ¶
	<t>		<t>
	Party that receives the CWT containing the proof-of-possession key in formation from the presenter.		Party that receives the CWT containing the proof-of-possession key in formation from the presenter.
	</t>		</t>
	<t>		<t>
	In the context of OAuth, this party is also called the OAuth Resource Server.		In the context of OAuth, this party is also called the OAuth Resource Server.
	</t>		</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	This specification provides examples in CBOR extended diagnostic		This specification provides examples in CBOR extended diagnostic
	notation, as defined in <xref target="RFC8610"		notation, as defined in <xref target="RFC8610" sectionFormat="of" section
	sectionFormat="of" section="G"/>.		="G"/>.
	The examples include line breaks for readability.		The examples include line breaks for readability.
	</t>		</t>
	</section>		</section>
	<section anchor="PoP" numbered="true" toc="default">		<section anchor="PoP" numbered="true" toc="default">
	<name>Representations for Proof-of-Possession Keys</name>		<name>Representations for Proof-of-Possession Keys</name>
	<t>		<t>
	By including a <tt>cnf</tt> (confirmation) claim in a CWT,		By including a <tt>cnf</tt> (confirmation) claim in a CWT,
	the issuer of the CWT declares that the presenter possesses a particular key		the issuer of the CWT declares that the presenter possesses a particular key
	and that the recipient can cryptographically confirm that		and that the recipient can cryptographically confirm that
	the presenter has possession of that key.		the presenter has possession of that key.
	The value of the <tt>cnf</tt> claim is a CBOR map		The value of the <tt>cnf</tt> claim is a CBOR map
	(which is defined in <xref target="RFC7049"		(which is defined in <xref target="RFC7049" sectionFormat="of" section="2
	sectionFormat="of" section="2.1"/>)		.1"/>)
	and the members of that map identify the proof-of-possession key.		and the members of that map identify the proof-of-possession key.
	</t>		</t>
	<t>		<t>
	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.		depending upon the application requirements.
	For instance, some applications may use		For instance, some applications may use
	the CWT <tt>sub</tt> (subject) claim <xref target="RFC8392" format="defau lt"/>		the CWT <tt>sub</tt> (subject) claim <xref target="RFC8392" format="defau lt"/>
	to identify the presenter.		to identify the presenter.
	Other applications may use		Other applications may use
	the <tt>iss</tt> (issuer) claim <xref target="RFC8392" format="default"/>		the <tt>iss</tt> (issuer) claim <xref target="RFC8392" format="default"/>
	to identify the presenter.		to identify the presenter.
	In some applications, the subject identifier might be relative to		In some applications, the subject identifier might be relative to
	the issuer identified by the <tt>iss</tt> claim.		the issuer identified by the <tt>iss</tt> claim.
	The actual mechanism used is dependent upon the application.		The actual mechanism used is dependent upon the application.
	The case in which the presenter is the subject of the CWT is analogous to		The case in which the presenter is the subject of the CWT is analogous to
	Security Assertion Markup Language (SAML) 2.0 <xref		Security Assertion Markup Language (SAML) 2.0 <xref target="OASIS.saml-co
	target="OASIS.saml-core-2.0-os" format="default"/> SubjectConfirmation		re-2.0-os" format="default"/> SubjectConfirmation
	usage.		usage.
	</t>		</t>
	<section anchor="Confirmation" numbered="true" toc="default">		<section anchor="Confirmation" numbered="true" toc="default">
	<name>Confirmation Claim</name>		<name>Confirmation Claim</name>
	<t>		<t>
	The <tt>cnf</tt> claim in the CWT is used to carry confirmation methods. Some of		The <tt>cnf</tt> claim in the CWT is used to carry confirmation methods. Some of
	them use proof-of-possession keys, while others do not. This design is		them use proof-of-possession keys, while others do not. This design is
	analogous to the SAML 2.0 <xref target="OASIS.saml-core-2.0-os" format="default "/> SubjectConfirmation		analogous to the SAML 2.0 <xref target="OASIS.saml-core-2.0-os" format="default "/> SubjectConfirmation
	element in which a number of different subject confirmation methods can		element in which a number of different subject confirmation methods can
	be included (including proof-of-possession key information).		be included (including proof-of-possession key information).
	</t>		</t>
	<t>		<t>
	The set of confirmation members that a		The set of confirmation members that a
	CWT must contain to be considered valid is context dependent		CWT must contain to be considered valid is context dependent
	and is outside the scope of this specification.		and is outside the scope of this specification.
	Specific applications of CWTs will require implementations		Specific applications of CWTs will require implementations
	to understand and process some confirmation members in particular ways.		to understand and process some confirmation members in particular ways.
	However, in the absence of such requirements, all confirmation members		However, in the absence of such requirements, all confirmation members
	that are not understood by implementations <bcp14>MUST</bcp14> be ignor ed.		that are not understood by implementations <bcp14>MUST</bcp14> be ignor ed.
	</t>		</t>
	<t>		<t><xref target="CnfReg" format="default"/> establishes the
	<xref target="CnfReg" format="default"/> establishes the
	IANA "CWT Confirmation Methods" registry for CWT <tt>cnf</tt>		IANA "CWT Confirmation Methods" registry for CWT <tt>cnf</tt>
	member values and registers the members defined by this specification.		member values and registers the members defined by this specification.
	Other specifications can register		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 using different key		conveying proof-of-possession keys using different key
	representations.		representations.
	</t>		</t>
	<t>		<t>
	The <tt>cnf</tt> claim value <bcp14>MUST</bcp14> represent only a single		The <tt>cnf</tt> claim value <bcp14>MUST</bcp14> represent only a single
	proof-of-possession key. At most one of the <tt>COSE_Key</tt>		proof-of-possession key. At most one of the <tt>COSE_Key</tt>
	skipping to change at line 224 ¶		skipping to change at line 214 ¶
	in <xref target="fig_cborMappings" format="default"/> may be		in <xref target="fig_cborMappings" format="default"/> may be
	present. Note that if an application		present. Note that if an application
	needs to represent multiple proof-of-possession keys in the same CWT, one way		needs to represent multiple proof-of-possession keys in the same CWT, one way
	for it to achieve this is to use other claim names (in addition t o		for it to achieve this is to use other claim names (in addition t o
	<tt>cnf</tt>) to hold the additional proof-of-possession		<tt>cnf</tt>) to hold the additional proof-of-possession
	key information. These claims could use the same syntax and seman tics as the		key information. These claims could use the same syntax and seman tics as the
	<tt>cnf</tt> claim. Those claims would be defined by		<tt>cnf</tt> claim. Those claims would be defined by
	applications or other specifications and could be registered in t he		applications or other specifications and could be registered in t he
	IANA "CBOR Web Token (CWT) Claims" registry <xref target="IANA.CW T.Claims" format="default"/>.		IANA "CBOR Web Token (CWT) Claims" registry <xref target="IANA.CW T.Claims" format="default"/>.
	</t>		</t>
	<table anchor="fig_cborMappings">		<table anchor="fig_cborMappings">
	<name>Summary of the <tt>cnf</tt> Names, Keys, and Value Types</name>		<name>Summary of the <tt>cnf</tt> Names, Keys, and Value Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th>Name</th>		<th>Name</th>
	<th>Key</th>		<th>Key</th>
	<th>Value type</th>		<th>Value type</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td>COSE_Key</td>		<td>COSE_Key</td>
	<td>1</td>		<td>1</td>
	<td>COSE_Key</td>		<td>COSE_Key</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>Encrypted_COSE_Key</td>		<td>Encrypted_COSE_Key</td>
	<td>2</td>		<td>2</td>
	<td>COSE_Encrypt or COSE_Encrypt0</td>		<td>COSE_Encrypt or COSE_Encrypt0</td>
	</tr>		</tr>
	<tr>		<tr>
	<td>kid</td>		<td>kid</td>
	<td>3</td>		<td>3</td>
	<td>binary string</td>		<td>binary string</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="PrivatePoP" numbered="true" toc="default">		<section anchor="PrivatePoP" numbered="true" toc="default">
	<name>Representation of an Asymmetric Proof-of-Possession Key</name>		<name>Representation of an Asymmetric Proof-of-Possession Key</name>
	<t>		<t>
	When the key held by the presenter is an asymmetric private key,		When the key held by the presenter is an asymmetric private key,
	the <tt>COSE_Key</tt> member		the <tt>COSE_Key</tt> member
	is a COSE_Key <xref target="RFC8152" format="default"/>		is a COSE_Key <xref target="RFC8152" format="default"/>
	representing the corresponding asymmetric public key.		representing the corresponding asymmetric public key.
	The following example demonstrates such a declaration		The following example demonstrates such a declaration
	in the CWT Claims Set of a CWT:		in the CWT Claims Set of a CWT:
	</t>		</t>
			<sourcecode type="cbor"><![CDATA[
	<sourcecode type="cbor"><![CDATA[
	{		{
	/iss/ 1 : "coaps://server.example.com",		/iss/ 1 : "coaps://server.example.com",
	/aud/ 3 : "coaps://client.example.org",		/aud/ 3 : "coaps://client.example.org",
	/exp/ 4 : 1879067471,		/exp/ 4 : 1879067471,
	/cnf/ 8 :{		/cnf/ 8 :{
	/COSE_Key/ 1 :{		/COSE_Key/ 1 :{
	/kty/ 1 : /EC2/ 2,		/kty/ 1 : /EC2/ 2,
	/crv/ -1 : /P-256/ 1,		/crv/ -1 : /P-256/ 1,
	/x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9		/x/ -2 : h'd7cc072de2205bdc1537a543d53c60a6acb62eccd890c7fa27c9
	e354089bbe13',		e354089bbe13',
	/y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e		/y/ -3 : h'f95e1d4b851a2cc80fff87d8e23f22afb725d535e515d020731e
	79a3b4e47120'		79a3b4e47120'
	}		}
	}		}
	}		}
	]]></sourcecode>		]]></sourcecode>
			<t>
	<t>
	The COSE_Key <bcp14>MUST</bcp14> contain the required key members		The COSE_Key <bcp14>MUST</bcp14> contain the required key members
	for a COSE_Key of that key type		for a COSE_Key of that key type
	and <bcp14>MAY</bcp14> contain other COSE_Key members,		and <bcp14>MAY</bcp14> contain other COSE_Key members,
	including the <tt>kid</tt> (Key ID) member.		including the <tt>kid</tt> (Key ID) member.
	</t>		</t>
	<t>		<t>
	The <tt>COSE_Key</tt> member <bcp14>MAY</bcp14> also be used for a COSE _Key		The <tt>COSE_Key</tt> member <bcp14>MAY</bcp14> also be used for a COSE _Key
	representing a symmetric key, provided that the CWT is encrypted		representing a symmetric key, provided that the CWT is encrypted
	so that the key is not revealed to unintended parties.		so that the key is not revealed to unintended parties.
	The means of encrypting a CWT is explained in <xref target="RFC8392" fo rmat="default"/>.		The means of encrypting a CWT is explained in <xref target="RFC8392" fo rmat="default"/>.
	If the CWT is not encrypted, the symmetric key <bcp14>MUST</bcp14>		If the CWT is not encrypted, the symmetric key <bcp14>MUST</bcp14>
	be encrypted as described in <xref target="SymmetricPoP"		be encrypted as described in <xref target="SymmetricPoP" format="defaul
	format="default"/>. This procedure is equivalent to		t"/>. This procedure is equivalent to
	the one defined in <xref target="RFC7800"		the one defined in <xref target="RFC7800" sectionFormat="of" section="3
	sectionFormat="of" section="3.3"/>.		.3"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="SymmetricPoP" numbered="true" toc="default">		<section anchor="SymmetricPoP" numbered="true" toc="default">
	<name>Representation of an Encrypted Symmetric Proof-of-Possession Key</ name>		<name>Representation of an Encrypted Symmetric Proof-of-Possession Key</ name>
	<t>		<t>
	When the key held by the presenter is a symmetric key,		When the key held by the presenter is a symmetric key,
	the <tt>Encrypted_COSE_Key</tt> member		the <tt>Encrypted_COSE_Key</tt> member
	is an encrypted COSE_Key <xref target="RFC8152" format="default"/>		is an encrypted COSE_Key <xref target="RFC8152" format="default"/>
	representing the symmetric key		representing the symmetric key
	encrypted to a key known to the recipient		encrypted to a key known to the recipient
	using COSE_Encrypt or COSE_Encrypt0.		using COSE_Encrypt or COSE_Encrypt0.
	</t>		</t>
	<t>		<t>
	The following example		The following example
	illustrates a symmetric key that could subsequently be encrypted for us e in the		illustrates a symmetric key that could subsequently be encrypted for us e in the
	<tt>Encrypted_COSE_Key</tt> member:		<tt>Encrypted_COSE_Key</tt> member:
	</t>		</t>
	<sourcecode type="cbor"><![CDATA[		<sourcecode type="cbor"><![CDATA[
	{		{
	/kty/ 1 : /Symmetric/ 4,		/kty/ 1 : /Symmetric/ 4,
	/alg/ 3 : /HMAC 256-256/ 5,		/alg/ 3 : /HMAC 256-256/ 5,
	/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df		/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
	e68449c65f885d1b73b49eae1'		e68449c65f885d1b73b49eae1'
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The COSE_Key representation		The COSE_Key representation
	is used as the plaintext when encrypting the key.		is used as the plaintext when encrypting the key.
	</t>		</t>
	<t>		<t>
	The following example CWT Claims Set of a CWT		The following example CWT Claims Set of a CWT
	illustrates the use of an encrypted symmetric key as the		illustrates the use of an encrypted symmetric key as the
	<tt>Encrypted_COSE_Key</tt> member value:		<tt>Encrypted_COSE_Key</tt> member value:
	</t>		</t>
			<sourcecode type="cbor"><![CDATA[
	<sourcecode type="cbor"><![CDATA[
	{		{
	/iss/ 1 : "coaps://server.example.com",		/iss/ 1 : "coaps://server.example.com",
	/sub/ 2 : "24400320",		/sub/ 2 : "24400320",
	/aud/ 3: "s6BhdRkqt3",		/aud/ 3: "s6BhdRkqt3",
	/exp/ 4 : 1311281970,		/exp/ 4 : 1311281970,
	/iat/ 5 : 1311280970,		/iat/ 5 : 1311280970,
	/cnf/ 8 : {		/cnf/ 8 : {
	/Encrypted_COSE_Key/ 2 : [		/Encrypted_COSE_Key/ 2 : [
	/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,		/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
	/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},		/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
	/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E		/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
	A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'		A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
	]		]
	}		}
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	The example above was generated with the key:		The example above was generated with the key:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	h'6162630405060708090a0b0c0d0e0f10'		h'6162630405060708090a0b0c0d0e0f10'
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="KidPoP" numbered="true" toc="default">		<section anchor="KidPoP" numbered="true" toc="default">
	<name>Representation of a Key ID for a Proof-of-Possession Key</name>		<name>Representation of a Key ID for a Proof-of-Possession Key</name>
	<t>		<t>
	The proof-of-possession key can also be identified using		The proof-of-possession key can also be identified using
	a Key ID instead of communicating the actual key,		a Key ID instead of communicating the actual key,
	provided the recipient is able to obtain the identified key		provided the recipient is able to obtain the identified key
	using the Key ID.		using the Key ID.
	skipping to change at line 376 ¶		skipping to change at line 361 ¶
	and that the recipient can cryptographically confirm		and that the recipient can cryptographically confirm
	the presenter's proof of possession of the key by including a		the presenter's proof of possession of the key by including a
	<tt>cnf</tt> claim in the CWT		<tt>cnf</tt> claim in the CWT
	whose value is a CBOR map containing a <tt>kid</tt> member		whose value is a CBOR map containing a <tt>kid</tt> member
	identifying the key.		identifying the key.
	</t>		</t>
	<t>		<t>
	The following example demonstrates such a declaration		The following example demonstrates such a declaration
	in the CWT Claims Set of a CWT:		in the CWT Claims Set of a CWT:
	</t>		</t>
	<sourcecode type="cbor"><![CDATA[		<sourcecode type="cbor"><![CDATA[
	{		{
	/iss/ 1 : "coaps://as.example.com",		/iss/ 1 : "coaps://as.example.com",
	/aud/ 3 : "coaps://resource.example.org",		/aud/ 3 : "coaps://resource.example.org",
	/exp/ 4 : 1361398824,		/exp/ 4 : 1361398824,
	/cnf/ 8 : {		/cnf/ 8 : {
	/kid/ 3 : h'dfd1aa976d8d4575a0fe34b96de2bfad'		/kid/ 3 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
	}		}
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>		<t>
	skipping to change at line 452 ¶		skipping to change at line 436 ¶
	<t>		<t>
	All the security considerations that		All the security considerations that
	are discussed in <xref target="RFC8392" format="default"/> also apply he re.		are discussed in <xref target="RFC8392" format="default"/> also apply he re.
	In addition, proof of possession introduces its own unique security issu es.		In addition, proof of possession introduces its own unique security issu es.
	Possessing a key is only valuable if it is kept secret.		Possessing a key is only valuable if it is kept secret.
	Appropriate means must be used to ensure that unintended parties		Appropriate means must be used to ensure that unintended parties
	do not learn private key or symmetric key values.		do not learn private key or symmetric key values.
	</t>		</t>
	<t>		<t>
	Applications utilizing proof of possession <bcp14>SHOULD</bcp14> also uti lize audience restriction,		Applications utilizing proof of possession <bcp14>SHOULD</bcp14> also uti lize audience restriction,
	as described in <xref target="RFC8392"		as described in <xref target="RFC8392" sectionFormat="of" section="3.1.3"
	sectionFormat="of" section="3.1.3"/>,		/>,
	because it provides additional protections.		because it provides additional protections.
	Audience restriction can be used by recipients to reject messages intende d for different recipients.		Audience restriction can be used by recipients to reject messages intende d for different recipients.
	(Of course, applications not using proof of possession can also benefit		(Of course, applications not using proof of possession can also benefit
	from using audience restriction to reject messages intended for different recipients.)		from using audience restriction to reject messages intended for different recipients.)
	</t>		</t>
	<t>		<t>
	CBOR Web Tokens with proof-of-possession keys are used in context of an a rchitecture,		CBOR Web Tokens with proof-of-possession keys are used in context of an a rchitecture,
	such as the ACE OAuth Framework <xref target="I-D.ietf-ace-oauth-authz" f ormat="default"/>,		such as the ACE OAuth Framework <xref target="I-D.ietf-ace-oauth-authz" f ormat="default"/>,
	in which protocols are used by a presenter to request these tokens		in which protocols are used by a presenter to request these tokens
	and to subsequently use them with recipients.		and to subsequently use them with recipients.
	skipping to change at line 488 ¶		skipping to change at line 471 ¶
	learns about the entity that created the CWT,		learns about the entity that created the CWT,
	since this will be important for any policy decisions.		since this will be important for any policy decisions.
	Integrity protection prevents an adversary from changing		Integrity protection prevents an adversary from changing
	any elements conveyed within the CWT payload.		any elements conveyed within the CWT payload.
	Special care has to be applied when carrying symmetric keys inside the CW T		Special care has to be applied when carrying symmetric keys inside the CW T
	since those not only require integrity protection		since those not only require integrity protection
	but also confidentiality protection.		but also confidentiality protection.
	</t>		</t>
	<t>		<t>
	As described in Section <xref target="RFC7515" section="6" sectionFormat= "bare">Key		As described in Section <xref target="RFC7515" section="6" sectionFormat= "bare">Key
	Identification</xref> and Appendix <xref target="RFC7515" section="D"		Identification</xref> and Appendix <xref target="RFC7515" section="D" sec
	sectionFormat="bare">Notes on Key Selection</xref> of <xref		tionFormat="bare">Notes on Key Selection</xref> of <xref target="RFC7515"/>, it
	target="RFC7515"/>, it is important to make		is important to make
	explicit trust decisions about the keys.		explicit trust decisions about the keys.
	Proof-of-possession signatures made with keys		Proof-of-possession signatures made with keys
	not meeting the application's trust criteria <bcp14>MUST NOT</bcp14> be r elied upon.		not meeting the application's trust criteria <bcp14>MUST NOT</bcp14> be r elied upon.
	</t>		</t>
	</section>		</section>
	<section anchor="Privacy" numbered="true" toc="default">		<section anchor="Privacy" numbered="true" toc="default">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>		<t>
	A proof-of-possession key can be used as a correlation handle if the same key		A proof-of-possession key can be used as a correlation handle if the same key
	is used on multiple occasions.		is used on multiple occasions.
	skipping to change at line 601 ¶		skipping to change at line 582 ¶
	<li>		<li>
	Claim Key: 8		Claim Key: 8
	</li>		</li>
	<li>		<li>
	Claim Value Type(s): map		Claim Value Type(s): map
	</li>		</li>
	<li>		<li>
	Change Controller: IESG		Change Controller: IESG
	</li>		</li>
	<li>		<li>
	Specification Document(s): <xref target="Confirmation"		Specification Document(s): <xref target="Confirmation" format="de
	format="default"/> of RFC 8747		fault"/> of RFC 8747
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="CnfReg" numbered="true" toc="default">		<section anchor="CnfReg" numbered="true" toc="default">
	<name>CWT Confirmation Methods Registry</name>		<name>CWT Confirmation Methods Registry</name>
	<t>		<t>
	This specification establishes the		This specification establishes the
	IANA "CWT Confirmation Methods" registry		IANA "CWT Confirmation Methods" registry
	for CWT <tt>cnf</tt> member values.		for CWT <tt>cnf</tt> member values.
	skipping to change at line 663 ¶		skipping to change at line 643 ¶
	preferably including URIs that		preferably including URIs that
	can be used to retrieve copies of the documents.		can be used to retrieve copies of the documents.
	An indication of the relevant		An indication of the relevant
	sections may also be included but is not required.		sections may also be included but is not required.
	Note that the designated experts and IANA must be able to obtain		Note that the designated experts and IANA must be able to obtain
	copies of the specification document(s) to perform their work.		copies of the specification document(s) to perform their work.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="CnfContents" numbered="true" toc="default">		<section anchor="CnfContents" numbered="true" toc="default">
	<name>Initial Registry Contents</name>		<name>Initial Registry Contents</name>
			<ul spacing="compact">
	<ul spacing="compact">
	<li>		<li>
	Confirmation Method Name: <tt>COSE_Key</tt>		Confirmation Method Name: <tt>COSE_Key</tt>
	</li>		</li>
	<li>		<li>
	Confirmation Method Description: COSE_Key Representing Public		Confirmation Method Description: COSE_Key Representing Public
	Key		Key
	</li>		</li>
	<li>		<li>
	JWT Confirmation Method Name: <tt>jwk</tt>		JWT Confirmation Method Name: <tt>jwk</tt>
	</li>		</li>
	<li>		<li>
	Confirmation Key: 1		Confirmation Key: 1
	</li>		</li>
	<li>		<li>
	Confirmation Value Type(s): COSE_Key structure		Confirmation Value Type(s): COSE_Key structure
	</li>		</li>
	<li>		<li>
	Change Controller: IESG		Change Controller: IESG
	</li>		</li>
	<li>		<li>
	Specification Document(s): <xref target="PrivatePoP"		Specification Document(s): <xref target="PrivatePoP" format="def
	format="default"/> of RFC 8747		ault"/> of RFC 8747
	</li>		</li>
	</ul>		</ul>
	<ul spacing="compact">		<ul spacing="compact">
	<li>		<li>
	Confirmation Method Name: <tt>Encrypted_COSE_Key</tt>		Confirmation Method Name: <tt>Encrypted_COSE_Key</tt>
	</li>		</li>
	<li>		<li>
	Confirmation Method Description: Encrypted COSE_Key		Confirmation Method Description: Encrypted COSE_Key
	</li>		</li>
	<li>		<li>
	JWT Confirmation Method Name: <tt>jwe</tt>		JWT Confirmation Method Name: <tt>jwe</tt>
	</li>		</li>
	skipping to change at line 712 ¶		skipping to change at line 690 ¶
	</li>		</li>
	<li>		<li>
	Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0		Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
	structure (with an optional corresponding COSE_Encrypt or		structure (with an optional corresponding COSE_Encrypt or
	COSE_Encrypt0 tag)		COSE_Encrypt0 tag)
	</li>		</li>
	<li>		<li>
	Change Controller: IESG		Change Controller: IESG
	</li>		</li>
	<li>		<li>
	Specification Document(s): <xref target="SymmetricPoP"		Specification Document(s): <xref target="SymmetricPoP" format="d
	format="default"/> of RFC 8747		efault"/> of RFC 8747
	</li>		</li>
	</ul>		</ul>
	<ul spacing="compact">		<ul spacing="compact">
	<li>		<li>
	Confirmation Method Name: <tt>kid</tt>		Confirmation Method Name: <tt>kid</tt>
	</li>		</li>
	<li>		<li>
	Confirmation Method Description: Key Identifier		Confirmation Method Description: Key Identifier
	</li>		</li>
	<li>		<li>
	skipping to change at line 736 ¶		skipping to change at line 713 ¶
	<li>		<li>
	Confirmation Key: 3		Confirmation Key: 3
	</li>		</li>
	<li>		<li>
	Confirmation Value Type(s): binary string		Confirmation Value Type(s): binary string
	</li>		</li>
	<li>		<li>
	Change Controller: IESG		Change Controller: IESG
	</li>		</li>
	<li>		<li>
	Specification Document(s): <xref target="KidPoP"		Specification Document(s): <xref target="KidPoP" format="default
	format="default"/> of RFC 8747		"/> of RFC 8747
	</li>		</li>
	</ul>		</ul>
			</section>
	</section>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<displayreference target="I-D.ietf-ace-oauth-authz" to="ACE-OAUTH"/>		<displayreference target="I-D.ietf-ace-oauth-authz" to="ACE-OAUTH"/>
	<displayreference target="RFC7515" to="JWS"/>		<displayreference target="RFC7515" to="JWS"/>
	<displayreference target="RFC7519" to="JWT"/>		<displayreference target="RFC7519" to="JWT"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7049.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7049.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8126.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8126.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8152.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8152.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8392.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8392.xml"/>
	skipping to change at line 776 ¶		skipping to change at line 751 ¶
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8259.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8259.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7800.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7800.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8610.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8610.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7515.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7515.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7519.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7519.xml"/>
			<reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-ope
	<reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-open.		n.org/security/saml/v2.0/saml-core-2.0-os.pdf">
	org/security/saml/v2.0/saml-core-2.0-os.pdf">
	<front>		<front>
	<title>Assertions and Protocol for the OASIS Security Assertion Mark up Language		<title>Assertions and Protocol for the OASIS Security Assertion Mark up Language
	(SAML) V2.0</title>		(SAML) V2.0</title>
	<author fullname="Scott Cantor" initials="S." surname="Cantor">		<author fullname="Scott Cantor" initials="S." surname="Cantor">
	<organization>Internet2</organization>		<organization>Internet2</organization>
	<address>		<address>
	<email>cantor.2@osu.edu</email>		<email>cantor.2@osu.edu</email>
	</address>		</address>
	</author>		</author>
	<author fullname="John Kemp" initials="J." surname="Kemp">		<author fullname="John Kemp" initials="J." surname="Kemp">
	skipping to change at line 807 ¶		skipping to change at line 781 ¶
	</address>		</address>
	</author>		</author>
	<author fullname="Eve Maler" initials="E." surname="Maler">		<author fullname="Eve Maler" initials="E." surname="Maler">
	<organization>Sun Microsystems</organization>		<organization>Sun Microsystems</organization>
	<address>		<address>
	<email>eve.maler@sun.com</email>		<email>eve.maler@sun.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2005" month="March"/>		<date year="2005" month="March"/>
	</front>		</front>
	<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>		<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
	</reference>		</reference>
	<reference anchor="IANA.JWT" target="http://www.iana.org/assignments/jwt ">		<reference anchor="IANA.JWT" target="http://www.iana.org/assignments/jwt ">
	<front>		<front>
	<title>JSON Web Token (JWT)</title>		<title>JSON Web Token (JWT)</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	skipping to change at line 837 ¶		skipping to change at line 810 ¶
	<contact fullname="Christer Holmberg"/>,		<contact fullname="Christer Holmberg"/>,
	<contact fullname="Benjamin Kaduk"/>,		<contact fullname="Benjamin Kaduk"/>,
	<contact fullname="Mirja Kühlewind"/>,		<contact fullname="Mirja Kühlewind"/>,
	<contact fullname="Yoav Nir"/>,		<contact fullname="Yoav Nir"/>,
	<contact fullname="Michael Richardson"/>,		<contact fullname="Michael Richardson"/>,
	<contact fullname="Adam Roach"/>,		<contact fullname="Adam Roach"/>,
	<contact fullname="Éric Vyncke"/>,		<contact fullname="Éric Vyncke"/>,
	and		and
	<contact fullname="Jim Schaad"/>.		<contact fullname="Jim Schaad"/>.
	</t>		</t>
	<t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran		<t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran S
	Selander"/> worked on this document as part of		elander"/> worked on this document as part of
	the CelticPlus projects CyberWI and CRITISEC, with funding from Vinnova.</t>		the CelticPlus projects CyberWI and CRITISEC, with funding from Vinnova.</t>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 29 change blocks.
	86 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/