Diff: rfc8747xml2.original.xml

	rfc8747xml2.original.xml	rfc8747.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	fc2629.xslt' ?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>
	<?rfc tocdepth="4"?>
	<?rfc tocindent="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>


	<rfc category="std" docName="draft-ietf-ace-cwt-proof-of-possession-11"	<rfc number="8747" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" c
	ipr="trust200902">	ategory="std"
		docName="draft-ietf-ace-cwt-proof-of-possession-11" ipr="trust200902"
		obsoletes="" updates="" submissionType="IETF" xml:lang="en"
		tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
		version="3">
		<!-- xml2rfc v2v3 conversion 2.38.0 -->
	<front>	<front>

	<title abbrev="Proof-of-Possession Key for CWTs">Proof-of-Possession Key Sem	<title abbrev="Proof-of-Possession Key for CWTs">Proof-of-Possession Key
	antics for CBOR Web Tokens (CWTs)</title>	Semantics for CBOR Web Tokens (CWTs)</title>
		<seriesInfo name="RFC" value="8747"/>
	<author fullname="Michael B. Jones" initials="M.B." 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>http://self-issued.info/</uri>	<uri>https://self-issued.info/</uri>
	</address>	</address>
	</author>	</author>


	<author initials="L." surname="Seitz" fullname="Ludwig Seitz">	<author initials="L." surname="Seitz" fullname="Ludwig Seitz">

	<organization>RISE SICS</organization>	<organization>Combitech</organization>
	<address>	<address>

	<postal>	<postal>
	<street>Scheelevaegen 17</street>	<street>Djaeknegatan 31</street>
	<city>Lund</city>	<city ascii="Malmo">Malmö</city>
	<code>223 70</code>	<code>211 35</code>
	<country>Sweden</country>	<country>Sweden</country>
	</postal>	</postal>
	<email>ludwig@ri.se</email>	<email>ludwig.seitz@combitech.se</email>
	</address>	</address>
	</author>	</author>


	<author initials="G." surname="Selander" fullname="Göran Selander">	<author initials="G." surname="Selander" fullname="Göran Selander">
	<organization>Ericsson AB</organization>	<organization>Ericsson AB</organization>
	<address>	<address>

	<postal>	<postal>
	<street>Färögatan 6</street>	<city>Kista</city>
	<city>Kista</city>	<code>164 80</code>
	<code>164 80</code>	<country>Sweden</country>
	<country>Sweden</country>	</postal>
	</postal>	<email>goran.selander@ericsson.com</email>
	<email>goran.selander@ericsson.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Samuel Erdtman" initials="S." surname="Erdtman">	<author fullname="Samuel Erdtman" initials="S." surname="Erdtman">
	<organization>Spotify</organization>	<organization>Spotify</organization>
	<address>	<address>

	<email>erdtman@spotify.com</email>	<email>erdtman@spotify.com</email>
	</address>	</address>
	</author>	</author>


	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
	<organization>Arm Ltd.</organization>	<organization>Arm Ltd.</organization>
	<address>	<address>

	<postal>	<postal>
	<street></street>	<street/>
	<code>6060</code> <city>Hall in Tirol</city>	<code>6060</code>
	<country>Austria</country>	<city>Hall in Tirol</city>
	</postal>	<country>Austria</country>
	<email>Hannes.Tschofenig@arm.com</email>	</postal>
		<email>Hannes.Tschofenig@arm.com</email>
	</address>	</address>
	</author>	</author>

		<date month="March" year="2020"/>
	<date day="31" month="October" year="2019"/>

	<area>Security</area>	<area>Security</area>
	<workgroup>ACE</workgroup>	<workgroup>ACE</workgroup>


	<keyword>CBOR Web Token</keyword>	<keyword>CBOR Web Token</keyword>
	<keyword>CWT</keyword>	<keyword>CWT</keyword>
	<keyword>Proof-of-Possession</keyword>	<keyword>Proof-of-Possession</keyword>
	<keyword>Holder-of-Key</keyword>	<keyword>Holder-of-Key</keyword>


	<abstract>	<abstract>
	<t>	<t>
	This specification describes how to declare in a CBOR Web Token (CWT)	This specification describes how to declare in a CBOR Web Token (CWT)
	(which is defined by RFC 8392)	(which is defined by RFC 8392)
	that the presenter of the CWT possesses a particular proof-of-possession key.	that the presenter of the CWT possesses a particular proof-of-possession key.
	Being able to prove possession of a key is also sometimes described as	Being able to prove possession of a key is also sometimes described as
	being the holder-of-key.	being the holder-of-key.
	This specification provides equivalent functionality to	This specification provides equivalent functionality to
	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800)	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800)
	but using Concise Binary Object Representation (CBOR) and CWTs	but using Concise Binary Object Representation (CBOR) and CWTs

	skipping to change at line 97 ¶	skipping to change at line 82 ¶
	(which is defined by RFC 8392)	(which is defined by RFC 8392)
	that the presenter of the CWT possesses a particular proof-of-possession key.	that the presenter of the CWT possesses a particular proof-of-possession key.
	Being able to prove possession of a key is also sometimes described as	Being able to prove possession of a key is also sometimes described as
	being the holder-of-key.	being the holder-of-key.
	This specification provides equivalent functionality to	This specification provides equivalent functionality to
	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800)	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800)
	but using Concise Binary Object Representation (CBOR) and CWTs	but using Concise Binary Object Representation (CBOR) and CWTs
	rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).	rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).
	</t>	</t>
	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

	<section title="Introduction" anchor="Introduction">	<section anchor="Introduction" numbered="true" toc="default">
		<name>Introduction</name>
	<t>	<t>

	This specification describes how a CBOR Web Token (CWT) <xref target="RF C8392"/> can declare	This specification describes how a CBOR Web Token (CWT) <xref target="RF C8392" format="default"/> can declare
	that the presenter of the CWT possesses a particular proof-of-possession (PoP) key.	that the presenter of the CWT possesses a particular proof-of-possession (PoP) key.
	Proof of possession of a key is also sometimes described as	Proof of possession of a key is also sometimes described as
	being the holder-of-key.	being the holder-of-key.
	This specification provides equivalent functionality to	This specification provides equivalent functionality to

	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" <xref targ	"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" <xref targ
	et="RFC7800"/>	et="RFC7800" format="default"/>
	but using Concise Binary Object Representation (CBOR) <xref target="RFC70	but using Concise Binary Object Representation (CBOR) <xref target="RFC70
	49"/>	49" format="default"/>
	and CWTs <xref target="RFC8392"/>	and CWTs <xref target="RFC8392" format="default"/>
	rather than JavaScript Object Notation (JSON) <xref target="RFC8259"/>	rather than JavaScript Object Notation (JSON) <xref target="RFC8259" form
	and JSON Web Tokens (JWTs) <xref target="JWT"/>.	at="default"/>
	</t>	and JSON Web Tokens (JWTs) <xref target="RFC7519" format="default"/>.
		</t>
	</section>	</section>

		<section anchor="Terminology" numbered="true" toc="default">
	<section title='Terminology' anchor='Terminology'>	<name>Terminology</name>
		<t>
	<t>	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	when, and only when, they appear in all capitals, as shown here.	to be interpreted as
	</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
	<t>	<t>
	This specification uses terms defined in	This specification uses terms defined in

	the CBOR Web Token (CWT) <xref target="RFC8392"/>,	the CBOR Web Token (CWT) <xref target="RFC8392" format="default"/>,
	CBOR Object Signing and Encryption (COSE) <xref target="RFC8152"/>, and	CBOR Object Signing and Encryption (COSE) <xref target="RFC8152" format="
	Concise Binary Object Representation (CBOR) <xref target="RFC7049"/>	default"/>, and
		Concise Binary Object Representation (CBOR) <xref target="RFC7049" format
		="default"/>
	specifications.	specifications.
	</t>	</t>


	<t>	<t>
	These terms are defined by this specification:	These terms are defined by this specification:
	</t>	</t>

		<dl newline="true" spacing="normal">
	<t>	<dt>Issuer</dt>
	<list style="hanging">	<dd>

	<t hangText="Issuer">
	<vspace/>
	Party that creates the CWT and binds the claims about the subject to the	Party that creates the CWT and binds the claims about the subject to the
	proof-of-possession key.	proof-of-possession key.

	</t>	</dd>
		<dt>Presenter</dt>
	<t hangText="Presenter">	<dd>
	<vspace/>	<t> Party that proves possession of a private key (for asymmetric
	Party that proves possession of a private key (for asymmetric key cry	key cryptography)
	ptography)
	or secret key (for symmetric key cryptography) to a recipient of a CW T.	or secret key (for symmetric key cryptography) to a recipient of a CW T.

	<vspace/>	</t>
		<t>
	In the context of OAuth, this party is also called the OAuth Client.	In the context of OAuth, this party is also called the OAuth Client.

	</t>	</t>
		</dd>
	<t hangText="Recipient">	<dt>Recipient</dt>
	<vspace/>	<dd>
		<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.

	<vspace/>	</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>
	</list>	</dl>
	</t>
	<t>	<t>
	This specification provides examples in CBOR extended diagnostic	This specification provides examples in CBOR extended diagnostic

	notation, as defined in Appendix G of <xref target="RFC8610"/>.	notation, as defined in <xref target="RFC8610"
		sectionFormat="of" section="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">
		<name>Representations for Proof-of-Possession Keys</name>


	<section title='Representations for Proof-of-Possession Keys' anchor="PoP">
	<t>	<t>

	By including a <spanx style="verb">cnf</spanx> (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 <spanx style="verb">cnf</spanx> claim is a CBOR map	The value of the <tt>cnf</tt> claim is a CBOR map
	(which is defined in Section 2.1 of <xref target="RFC7049"/>)	(which is defined in <xref target="RFC7049"
		sectionFormat="of" section="2.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 <spanx style="verb">sub</spanx> (subject) claim <xref target="RFC 8392"/>,	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 <spanx style="verb">iss</spanx> (issuer) claim <xref target="RFC8392" />	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 <spanx style="verb">iss</spanx> 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 target="OASIS.saml-co	Security Assertion Markup Language (SAML) 2.0 <xref
	re-2.0-os"/> SubjectConfirmation usage.	target="OASIS.saml-core-2.0-os" format="default"/> SubjectConfirmation
		usage.
	</t>	</t>

		<section anchor="Confirmation" numbered="true" toc="default">
	<section title="Confirmation Claim" anchor="Confirmation">	<name>Confirmation Claim</name>
	<t>	<t>
	The <spanx style="verb">cnf</spanx> claim in the CWT is used to carry confirma	The <tt>cnf</tt> claim in the CWT is used to carry confirmation methods. Some
	tion methods. Some of	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"/> SubjectConfir	analogous to the SAML 2.0 <xref target="OASIS.saml-core-2.0-os" format="default
	mation	"/> 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 MUST be ignored.	that are not understood by implementations <bcp14>MUST</bcp14> be ignor
	</t>	ed.
	<t>	</t>
	This specification establishes the	<t>
	IANA "CWT Confirmation Methods" registry for these members	<xref target="CnfReg" format="default"/> establishes the
	in <xref target="CnfReg"/> and registers the members defined by this sp	IANA "CWT Confirmation Methods" registry for CWT <tt>cnf</tt>
	ecification.	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 <spanx style="verb">cnf</spanx> claim value MUST represent on	The <tt>cnf</tt> claim value <bcp14>MUST</bcp14> represent only a
	ly a single	single
	proof-of-possession key. At most one of the <spanx style="verb">C	proof-of-possession key. At most one of the <tt>COSE_Key</tt>
	OSE_Key</spanx>	and <tt>Encrypted_COSE_Key</tt> confirmation values defined
	and <spanx style="verb">Encrypted_COSE_Key</spanx> confirmation v	in <xref target="fig_cborMappings" format="default"/> may be
	alues defined	present. Note that if an application
	in <xref target="fig:cborMappings"/> may be 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	for it to achieve this is to use other claim names (in addition t
	o	o
	<spanx style="verb">cnf</spanx>, to hold the additional proof-of-	<tt>cnf</tt>) to hold the additional proof-of-possession
	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

	<spanx style="verb">cnf</spanx> claim. Those claims would be defi ned 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 Claims" registry <xref target="IANA.CWT.Clai	IANA "CBOR Web Token (CWT) Claims" registry <xref target="IANA.CW
	ms"/>.	T.Claims" format="default"/>.
	</t>	</t>
	<t>	<table anchor="fig_cborMappings">
	<figure align="center" anchor="fig:cborMappings"	<name>Summary of the <tt>cnf</tt> Names, Keys, and Value Types</name>
	title="Summary of the cnf names, keys, and value types">	<thead>
	<artwork><![CDATA[	<tr>
	/--------------------+-----+-------------------------------\	<th>Name</th>
	\| Name \| Key \| Value type \|	<th>Key</th>
	\|--------------------+-----+-------------------------------\|	<th>Value type</th>
	\| COSE_Key \| 1 \| COSE_Key \|	</tr>
	\| Encrypted_COSE_Key \| 2 \| COSE_Encrypt or COSE_Encrypt0 \|	</thead>
	\| kid \| 3 \| binary string \|	<tbody>
	\--------------------+-----+-------------------------------/	<tr>
	]]></artwork>	<td>COSE_Key</td>
	</figure>	<td>1</td>
	</t>	<td>COSE_Key</td>
		</tr>
		<tr>
		<td>Encrypted_COSE_Key</td>
		<td>2</td>
		<td>COSE_Encrypt or COSE_Encrypt0</td>
		</tr>
		<tr>
		<td>kid</td>
		<td>3</td>
		<td>binary string</td>
		</tr>
		</tbody>
		</table>
	</section>	</section>

		<section anchor="PrivatePoP" numbered="true" toc="default">
	<section title="Representation of an Asymmetric Proof-of-Possession Key" a	<name>Representation of an Asymmetric Proof-of-Possession Key</name>
	nchor="PrivatePoP">	<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 <spanx style="verb">COSE_Key</spanx> member	the <tt>COSE_Key</tt> member
	is a COSE_Key <xref target="RFC8152"/>	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>
	<figure>
	<artwork><![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'
	}
	}	}
	}	}

	]]></artwork>	}
	</figure>	]]></sourcecode>

	<t>
	The COSE_Key MUST contain the required key members for a COSE_Key of th
	at key type
	and MAY contain other COSE_Key members,
	including the <spanx style="verb">kid</spanx> (Key ID) member.
	</t>


	<t>	<t>
	The <spanx style="verb">COSE_Key</spanx> member MAY also be used for a	The COSE_Key <bcp14>MUST</bcp14> contain the required key members
	COSE_Key	for a COSE_Key of that key type
		and <bcp14>MAY</bcp14> contain other COSE_Key members,
		including the <tt>kid</tt> (Key ID) member.
		</t>
		<t>
		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"/>.	The means of encrypting a CWT is explained in <xref target="RFC8392" fo
	If the CWT is not encrypted, the symmetric key MUST be encrypted as des	rmat="default"/>.
	cribed in <xref target="SymmetricPoP"/>. This procedure is equivalent to	If the CWT is not encrypted, the symmetric key <bcp14>MUST</bcp14>
	the one defined in section 3.3 of <xref target="RFC7800"/>.	be encrypted as described in <xref target="SymmetricPoP"
	</t>	format="default"/>. This procedure is equivalent to
		the one defined in <xref target="RFC7800"
		sectionFormat="of" section="3.3"/>.
		</t>
	</section>	</section>

		<section anchor="SymmetricPoP" numbered="true" toc="default">
	<section title="Representation of an Encrypted Symmetric Proof-of-Possessi	<name>Representation of an Encrypted Symmetric Proof-of-Possession Key</
	on Key" anchor="SymmetricPoP">	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 <spanx style="verb">Encrypted_COSE_Key</spanx> member	the <tt>Encrypted_COSE_Key</tt> member
	is an encrypted COSE_Key <xref target="RFC8152"/>	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

	<spanx style="verb">Encrypted_COSE_Key</spanx> member:	<tt>Encrypted_COSE_Key</tt> member:
	</t>	</t>
	<figure>	<sourcecode type="cbor"><![CDATA[
	<artwork><![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>
	]]></artwork>	<t>
	</figure>
	<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

	<spanx style="verb">Encrypted_COSE_Key</spanx> member value:	<tt>Encrypted_COSE_Key</tt> member value:
	</t>	</t>
	<figure>
	<artwork><![CDATA[
	{
	/iss/ 1 : "coaps://server.example.com",
	/sub/ 2 : "24400320",
	/aud/ 3: "s6BhdRkqt3",
	/exp/ 4 : 1311281970,
	/iat/ 5 : 1311280970,
	/cnf/ 8 : {
	/Encrypted_COSE_Key/ 2 : [
	/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
	/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
	/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
	A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
	]
	}
	}

	]]></artwork>
	</figure>


	<t>	<sourcecode type="cbor"><![CDATA[
		{
		/iss/ 1 : "coaps://server.example.com",
		/sub/ 2 : "24400320",
		/aud/ 3: "s6BhdRkqt3",
		/exp/ 4 : 1311281970,
		/iat/ 5 : 1311280970,
		/cnf/ 8 : {
		/Encrypted_COSE_Key/ 2 : [
		/protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
		/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
		/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
		A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
		]
		}
		}
		]]></sourcecode>
		<t>
	The example above was generated with the key:	The example above was generated with the key:

	</t>	</t>
	<figure>	<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork><![CDATA[	h'6162630405060708090a0b0c0d0e0f10'
	h'6162630405060708090a0b0c0d0e0f10'
	]]></artwork>	]]></artwork>

	</figure>
	</section>	</section>

		<section anchor="KidPoP" numbered="true" toc="default">
	<section title="Representation of a Key ID for a Proof-of-Possession Key"	<name>Representation of a Key ID for a Proof-of-Possession Key</name>
	anchor="KidPoP">	<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.


	In this case,	In this case,
	the issuer of a CWT declares that the presenter possesses a particular key	the issuer of a CWT declares that the presenter possesses a particular key
	and that the recipient can cryptographically confirm	and that the recipient can cryptographically confirm

	proof of possession of the key by the presenter by including a	the presenter's proof of possession of the key by including a
	<spanx style="verb">cnf</spanx> claim in the CWT	<tt>cnf</tt> claim in the CWT
	whose value is a CBOR map with the CBOR map containing a	whose value is a CBOR map containing a <tt>kid</tt> member
	<spanx style="verb">kid</spanx> 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>
	<figure>	<sourcecode type="cbor"><![CDATA[
	<artwork><![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'
	}
	}	}

	]]></artwork>	}
	</figure>	]]></sourcecode>
	<t>	<t>
	The content of the <spanx style="verb">kid</spanx> value is application	The content of the <tt>kid</tt> value is application specific.
	specific.
	For instance, some applications may choose to use a cryptographic hash of the public key	For instance, some applications may choose to use a cryptographic hash of the public key

	value as the <spanx style="verb">kid</spanx> value.	value as the <tt>kid</tt> value.
	</t>	</t>
	<t>	<t>
	Note that the use of a Key ID to identify a proof-of-possession key nee	Note that the use of a Key ID to identify a proof-of-possession key
	ds to be carefully circumscribed,	needs to be carefully circumscribed,
	as described below and in <xref target="Operational"/>.	as described below and in <xref target="Operational" format="default"/>
		.
	In cases where the Key ID is not a cryptographic value derived from the key	In cases where the Key ID is not a cryptographic value derived from the key
	or where not all of the parties involved are validating the cryptograph ic derivation,	or where not all of the parties involved are validating the cryptograph ic derivation,

	implementers should expect collisions, where different keys are assigne d the same Key ID.	implementers should expect collisions where different keys are assigned the same Key ID.
	Recipients of a CWT with a PoP key linked through only a Key ID should be prepared to handle	Recipients of a CWT with a PoP key linked through only a Key ID should be prepared to handle
	such situations.	such situations.

	</t>	</t>
	<t>	<t>
	In the world of constrained Internet of Things (IoT) devices,	In the world of constrained Internet of Things (IoT) devices,
	there is frequently a restriction on the size of Key IDs,	there is frequently a restriction on the size of Key IDs,
	either because of table constraints or a desire to keep message sizes s mall.	either because of table constraints or a desire to keep message sizes s mall.

	</t>	</t>
	<t>Note that the value of a Key ID for a specific key is not	<t>Note that the value of a Key ID for a specific key is not
	necessarily the same for different parties. When sending a COSE	necessarily the same for different parties. When sending a COSE
	encrypted message with a shared key, the Key ID may be different on	encrypted message with a shared key, the Key ID may be different on
	both sides of the conversation, with the appropriate one being included	both sides of the conversation, with the appropriate one being included
	in the message based on the recipient of the message.	in the message based on the recipient of the message.

	</t>	</t>
	</section>

	<!--
	<section title="Representation of a URL for a Proof-of-Possession Key" anc
	hor="jkuPoP">

	<t>
	The proof-of-possession key can be passed by reference
	instead of being passed by value.
	This is done using the <spanx style="verb">jku</spanx> member.
	Its value is a URI <xref target="RFC3986"/> that refers to a
	resource for a set of JSON-encoded public keys represented as a JWK Set
	<xref target="JWK" />,
	one of which is the proof-of-possession key.
	If there are multiple keys in the referenced JWK Set document,
	a <spanx style="verb">kid</spanx> member MUST also be included
	with the referenced key's JWK also containing the same <spanx style="ve
	rb">kid</spanx> value.
	</t>
	<t>
	The protocol used to acquire the resource MUST provide
	integrity protection. An HTTP GET request to retrieve the
	JWK Set MUST use TLS
	<xref target="RFC5246"/> and
	the identity of the server MUST be validated, as per
	Section 6 of <xref target="RFC6125">RFC 6125</xref>.
	</t>
	<t>
	The following example demonstrates such a declaration
	in the CWT Claims Set of a CWT:
	</t>
	<figure>
	<artwork><![CDATA[
	{
	"iss": "https://server.example.com",
	"sub": "17760704",
	"aud": "https://client.example.org",
	"exp": 1440804813,
	"cnf":{
	"jku": "https://keys.example.net/pop-keys.json",
	"kid": "2015-08-28"
	}
	}
	]]></artwork>
	</figure>
	</section>	</section>


	<section title="Specifics Intentionally Not Specified" anchor="NotSpecifie	<section anchor="NotSpecified" numbered="true" toc="default">
	d">	<name>Specifics Intentionally Not Specified</name>
	<t>	<t>
	Proof of possession is often demonstrated by having the presenter sign	Proof of possession is often demonstrated by having the presenter sign
	a value determined by the recipient using the key possessed by the pres enter.	a value determined by the recipient using the key possessed by the pres enter.
	This value is sometimes called a "nonce" or a "challenge".	This value is sometimes called a "nonce" or a "challenge".
	There are, however, also other means to demonstrate freshness of the e xchange	There are, however, also other means to demonstrate freshness of the e xchange
	and to link the proof-of-possession key to the participating parties,	and to link the proof-of-possession key to the participating parties,
	as demonstrated by various authentication and key exchange protocols.	as demonstrated by various authentication and key exchange protocols.

	</t>	</t>
	<t>	<t>
	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,	are intentionally not described in this specification,
	as different protocols will communicate this information in different w ays.	as different protocols will communicate this information in different w ays.
	Likewise, the means of communicating the signed nonce is also not speci fied,	Likewise, the means of communicating the signed nonce is also not speci fied,
	as this is also protocol specific.	as this is also protocol specific.

	</t>	</t>
	<t>	<t>
	Note that other means of proving possession of the key	Note that other means of proving possession of the key
	exist, which could be used in conjunction with a CWT's confirmation key .	exist, which could be used in conjunction with a CWT's confirmation key .
	Applications making use of such alternate means are encouraged	Applications making use of such alternate means are encouraged

	to register them in the IANA "CWT Confirmation Methods" registry	to register them in the IANA "CBOR Web Token (CWT) Confirmation Methods
	established in <xref target="CnfReg"/>.	" registry
	</t>	established in <xref target="CnfReg" format="default"/>.
		</t>
	</section>	</section>


	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>
	All the security considerations that	All the security considerations that

	are discussed in <xref target="RFC8392"/> also apply here.	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 SHOULD also utilize audience r	Applications utilizing proof of possession <bcp14>SHOULD</bcp14> also uti
	estriction,	lize audience restriction,
	as described in Section 3.1.3 of <xref target="RFC8392"/>,	as described in <xref target="RFC8392"
	as it provides additional protections.	sectionFormat="of" section="3.1.3"/>,
		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"/> ,	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.
	Proof of possession only provides the intended security gains when the	Proof of possession only provides the intended security gains when the
	proof is known to be current and not subject to replay attacks;	proof is known to be current and not subject to replay attacks;
	security protocols using mechanisms such as nonces and timestamps can be used to	security protocols using mechanisms such as nonces and timestamps can be used to

	avoid the risk of replay when performing proof of possession for a token.	avoid the risk of replay when performing proof of possession for a
		token.

	Note that a discussion of the architecture or specific protocols that	Note that a discussion of the architecture or specific protocols that

	CWT proof-of-possession tokens are used with is beyond the scope of this specification.	CWTs with proof-of-possession keys are used with is beyond the scope of t his specification.
	</t>	</t>
	<t>	<t>
	As is the case with other information included in a CWT,	As is the case with other information included in a CWT,
	it is necessary to apply data origin authentication and integrity protect ion	it is necessary to apply data origin authentication and integrity protect ion
	(via a keyed message digest or a digital signature).	(via a keyed message digest or a digital signature).
	Data origin authentication ensures that the recipient of the CWT	Data origin authentication ensures that the recipient of the CWT

	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 6 (Key Identification) and Appendix D (Notes on K	As described in Section <xref target="RFC7515" section="6" sectionFormat=
	ey Selection)	"bare">Key
	of <xref target="JWS"/>, it is important to make explicit trust decisions	Identification</xref> and Appendix <xref target="RFC7515" section="D"
	about the keys.	sectionFormat="bare">Notes on Key Selection</xref> of <xref
		target="RFC7515"/>, it is important to make
		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 MUST NOT be relied 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" title="Privacy Considerations">	<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.
	Thus, for privacy reasons, it is recommended that different proof-of-poss ession keys	Thus, for privacy reasons, it is recommended that different proof-of-poss ession keys
	be used when interacting with different parties.	be used when interacting with different parties.
	</t>	</t>
	</section>	</section>

		<section anchor="Operational" numbered="true" toc="default">
	<section anchor="Operational" title="Operational Considerations">	<name>Operational Considerations</name>
	<t>	<t>
	The use of CWTs with proof-of-possession keys requires additional informa tion	The use of CWTs with proof-of-possession keys requires additional informa tion
	to be shared between the involved parties in order to ensure correct proc essing.	to be shared between the involved parties in order to ensure correct proc essing.
	The recipient needs to be able to use credentials to verify the authentic ity and	The recipient needs to be able to use credentials to verify the authentic ity and

	integrity of the CWT. Furthermore, the recipient may need to be able to	integrity of the CWT. Furthermore, the recipient may need to be able to d
	decrypt	ecrypt
	either the whole CWT or the encrypted parts thereof (see <xref target="Sy	either the whole CWT or the encrypted parts thereof (see <xref target="Sy
	mmetricPoP"/>).	mmetricPoP" format="default"/>).
	This requires the recipient to know information about the issuer.	This requires the recipient to know information about the issuer.
	Likewise, there needs to be agreement between the issuer and the recipien t	Likewise, there needs to be agreement between the issuer and the recipien t
	about the claims being used (which is also true of CWTs in general).	about the claims being used (which is also true of CWTs in general).
	</t>	</t>
	<t>	<t>
	When an issuer creates a CWT containing a Key ID claim, it needs to make sure that	When an issuer creates a CWT containing a Key ID claim, it needs to make sure that
	it does not issue another CWT with different claims containing the same K ey ID	it does not issue another CWT with different claims containing the same K ey ID
	within the lifetime of the CWTs, unless intentionally desired.	within the lifetime of the CWTs, unless intentionally desired.
	Failure to do so may allow one party to impersonate another party,	Failure to do so may allow one party to impersonate another party,
	with the potential to gain additional privileges.	with the potential to gain additional privileges.
	A case where such reuse of a Key ID would be intentional is when a presen ter obtains	A case where such reuse of a Key ID would be intentional is when a presen ter obtains

	a CWT with different claims (e.g., extended scope) for the same recipient , but wants to	a CWT with different claims (e.g., extended scope) for the same recipient but wants to
	continue using an existing security association (e.g., a DTLS session) bo und to the key	continue using an existing security association (e.g., a DTLS session) bo und to the key
	identified by the Key ID.	identified by the Key ID.
	Likewise, if PoP keys are used for multiple different kinds of CWTs in an application	Likewise, if PoP keys are used for multiple different kinds of CWTs in an application
	and the PoP keys are identified by Key IDs, care must be taken to keep th e keys	and the PoP keys are identified by Key IDs, care must be taken to keep th e keys
	for the different kinds of CWTs segregated so that an attacker cannot	for the different kinds of CWTs segregated so that an attacker cannot
	cause the wrong PoP key to be used by using a valid Key ID	cause the wrong PoP key to be used by using a valid Key ID
	for the wrong kind of CWT.	for the wrong kind of CWT.
	Using an audience restriction for the CWT would be one strategy to mitiga te this risk.	Using an audience restriction for the CWT would be one strategy to mitiga te this risk.
	</t>	</t>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>

	<t>	<t>
	The following registration procedure is used for all the	The following registration procedure is used for all the
	registries established by this specification.	registries established by this specification.
	</t>	</t>
	<t>	<t>
	Values are registered on a Specification Required	Values are registered on a Specification Required

	<xref target="RFC8126"/> basis after a three-week review period on the cw	<xref target="RFC8126" format="default"/> basis after a three-week review
	t-reg-review@ietf.org mailing	period on the <cwt-reg-review@ietf.org> mailing
	list, on the advice of one or more Designated Experts. However, to allow	list, on the advice of one or more designated experts. However, to allow
	for the	for the
	allocation of values prior to publication, the Designated Experts may app	allocation of values prior to publication, the designated experts may app
	rove	rove
	registration once they are satisfied that such a specification will be pu blished.	registration once they are satisfied that such a specification will be pu blished.

	[[ Note to the RFC Editor:	</t>
	The name of the mailing list should be determined in consultation
	with the IESG and IANA. Suggested name: cwt-reg-review@ietf.org. ]]
	</t>
	<t>	<t>
	Registration requests sent to the mailing list for review should use	Registration requests sent to the mailing list for review should use
	an appropriate subject	an appropriate subject
	(e.g., "Request to Register CWT Confirmation Method: example").	(e.g., "Request to Register CWT Confirmation Method: example").
	Registration requests that are undetermined for	Registration requests that are undetermined for
	a period longer than 21 days can be brought directly to IANA's attention	a period longer than 21 days can be brought directly to IANA's attention
	(using the iana@iana.org mailing list) for resolution.	(using the iana@iana.org mailing list) for resolution.
	</t>	</t>
	<t>	<t>

	Designated Experts should determine whether a registration request contai ns	Designated experts should determine whether a registration request contai ns
	enough information for the registry to be populated with the new values a nd	enough information for the registry to be populated with the new values a nd
	whether the proposed new functionality already exists.	whether the proposed new functionality already exists.
	In the case of an incomplete registration	In the case of an incomplete registration
	or an attempt to register already existing functionality,	or an attempt to register already existing functionality,

	the Designated Experts should ask for corrections or reject the registrat ion.	the designated experts should ask for corrections or reject the registrat ion.
	</t>	</t>
	<t>	<t>

	It is suggested that multiple Designated Experts be appointed who are abl e to	It is suggested that multiple designated experts be appointed who are abl e to
	represent the perspectives of different applications using this specifica tion	represent the perspectives of different applications using this specifica tion
	in order to enable broadly informed review of registration decisions.	in order to enable broadly informed review of registration decisions.
	In cases where a registration decision could be perceived as	In cases where a registration decision could be perceived as

	creating a conflict of interest for a particular Expert,	creating a conflict of interest for a particular expert,
	that Expert should defer to the judgment of the other Experts.	that expert should defer to the judgment of the other experts.
	</t>	</t>

		<section anchor="ClaimsRegistry" numbered="true" toc="default">
	<section anchor="ClaimsRegistry" title="CBOR Web Token Claims Registration	<name>CBOR Web Token Claims Registration</name>
	">	<t>
	<t>	This specification registers the <tt>cnf</tt> claim in the IANA
	This specification registers the <spanx style="verb">cnf</spanx> claim	"CBOR Web Token (CWT) Claims" registry <xref target="IANA.CWT.Claims" f
	in the IANA	ormat="default"/>,
	"CBOR Web Token Claims" registry <xref target="IANA.CWT.Claims"/>	established by <xref target="RFC8392" format="default"/>.
	established by <xref target="RFC8392"/>.	</t>
	</t>	<section anchor="ClaimsContents" numbered="true" toc="default">
		<name>Registry Contents</name>
	<section anchor='ClaimsContents' title='Registry Contents'>	<ul spacing="normal">
	<t>	<li>
	<?rfc subcompact="yes"?>	Claim Name: <tt>cnf</tt>
	<list style='symbols'>	</li>
	<t>	<li>
	Claim Name: <spanx style="verb">cnf</spanx>
	</t>
	<t>
	Claim Description: Confirmation	Claim Description: Confirmation

	</t>	</li>
	<t>	<li>
	JWT Claim Name: <spanx style="verb">cnf</spanx>	JWT Claim Name: <tt>cnf</tt>
	</t>	</li>
	<t>	<li>
	Claim Key: TBD (maybe 8)	Claim Key: 8
	</t>	</li>
	<t>	<li>
	Claim Value Type(s): map	Claim Value Type(s): map

	</t>	</li>
	<t>	<li>
	Change Controller: IESG	Change Controller: IESG

	</t>	</li>
	<t>	<li>
	Specification Document(s): <xref target="Confirmation"/> of [[ th	Specification Document(s): <xref target="Confirmation"
	is document ]]	format="default"/> of RFC 8747
	</t>	</li>
	</list>	</ul>
	</t>	</section>
	</section>
	<?rfc subcompact="no"?>
	</section>	</section>

		<section anchor="CnfReg" numbered="true" toc="default">
	<section title="CWT Confirmation Methods Registry" anchor="CnfReg">	<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 <spanx style="verb">cnf</spanx> member values.	for CWT <tt>cnf</tt> member values.
	The registry records the confirmation method member	The registry records the confirmation method member
	and a reference to the specification that defines it.	and a reference to the specification that defines it.

	</t>	</t>
		<section anchor="CnfTemplate" numbered="true" toc="default">
	<section title="Registration Template" anchor="CnfTemplate">	<name>Registration Template</name>
	<t>	<dl newline="true" spacing="normal">
	<list style='hanging'>	<dt>Confirmation Method Name:</dt>
	<t hangText='Confirmation Method Name:'>	<dd>
	<vspace/>
	The human-readable name requested (e.g., "kid").	The human-readable name requested (e.g., "kid").

	</t>	</dd>
	<t hangText='Confirmation Method Description:'>	<dt>Confirmation Method Description:</dt>
	<vspace/>	<dd>
	Brief description of the confirmation method (e.g., "Key Identif ier").	Brief description of the confirmation method (e.g., "Key Identif ier").

	</t>	</dd>
	<t hangText='JWT Confirmation Method Name:'>	<dt>JWT Confirmation Method Name:</dt>
	<vspace/>	<dd>
	Claim Name of the equivalent JWT confirmation method value,	Claim Name of the equivalent JWT confirmation method value,

	as registered in <xref target="IANA.JWT.Claims"/>.	as registered in the "JSON Web Token Claims" subregistry in
		the "JSON Web Token (JWT)" registry <xref target="IANA.JWT" forma
		t="default"/>.
	CWT claims should normally have a corresponding JWT claim.	CWT claims should normally have a corresponding JWT claim.
	If a corresponding JWT claim would not make sense,	If a corresponding JWT claim would not make sense,

	the Designated Experts can choose to accept registrations	the designated experts can choose to accept registrations
	for which the JWT Claim Name is listed as "N/A".	for which the JWT Claim Name is listed as "N/A".

	</t>	</dd>
	<t hangText='Confirmation Key:'>	<dt>Confirmation Key:</dt>
	<vspace/>	<dd>
	CBOR map key value for the confirmation method.	CBOR map key value for the confirmation method.

	</t>	</dd>
	<t hangText='Confirmation Value Type(s):'>	<dt>Confirmation Value Type(s):</dt>
	<vspace/>	<dd>
	CBOR types that can be used for the confirmation method value.	CBOR types that can be used for the confirmation method value.

	</t>	</dd>
	<t hangText='Change Controller:'>	<dt>Change Controller:</dt>
	<vspace/>	<dd>
	For Standards Track RFCs, list the "IESG". For others, give the name of the	For Standards Track RFCs, list the "IESG". For others, give the name of the
	responsible party.	responsible party.

	</t>	</dd>
	<t hangText='Specification Document(s):'>	<dt>Specification Document(s):</dt>
	<vspace/>	<dd>
	Reference to the document or documents that specify the paramete r,	Reference to the document or documents that specify the paramete r,
	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.

	</t>	</dd>
	</list>	</dl>
	</t>
	</section>	</section>

		<section anchor="CnfContents" numbered="true" toc="default">
		<name>Initial Registry Contents</name>


	<section title="Initial Registry Contents" anchor="CnfContents">	<ul spacing="compact">
	<t> <?rfc subcompact="yes"?>	<li>
	<list style='symbols'>	Confirmation Method Name: <tt>COSE_Key</tt>
	<t>	</li>
	Confirmation Method Name: <spanx style="verb">COSE_Key</spanx>	<li>
	</t>	Confirmation Method Description: COSE_Key Representing Public
	<t>	Key
	Confirmation Method Description: COSE_Key Representing Public Ke	</li>
	y	<li>
	</t>	JWT Confirmation Method Name: <tt>jwk</tt>
	<t>	</li>
	JWT Confirmation Method Name: <spanx style="verb">jwk</spanx>	<li>
	</t>	Confirmation Key: 1
	<t>	</li>
	Confirmation Key: 1	<li>
	</t>	Confirmation Value Type(s): COSE_Key structure
	<t>	</li>
	Confirmation Value Type(s): COSE_Key structure	<li>
	</t>
	<t>
	Change Controller: IESG	Change Controller: IESG

	</t>	</li>
	<t>	<li>
	Specification Document(s): <xref target="PrivatePoP"/> of [[ thi	Specification Document(s): <xref target="PrivatePoP"
	s document ]]	format="default"/> of RFC 8747
	</t>	</li>
	</list>	</ul>
	</t>	<ul spacing="compact">
	<t>	<li>
	<list style='symbols'>	Confirmation Method Name: <tt>Encrypted_COSE_Key</tt>
	<t>	</li>
	Confirmation Method Name: <spanx style="verb">Encrypted_COSE_Key	<li>
	</spanx>
	</t>
	<t>
	Confirmation Method Description: Encrypted COSE_Key	Confirmation Method Description: Encrypted COSE_Key

	</t>	</li>
	<t>	<li>
	JWT Confirmation Method Name: <spanx style="verb">jwe</spanx>	JWT Confirmation Method Name: <tt>jwe</tt>
	</t>	</li>
	<t>	<li>
	Confirmation Key: 2	Confirmation Key: 2
	</t>	</li>
	<t>	<li>
	Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 structu	Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
	re (with an optional corresponding COSE_Encrypt or COSE_Encrypt0 tag)	structure (with an optional corresponding COSE_Encrypt or
	</t>	COSE_Encrypt0 tag)
	<t>	</li>
		<li>
	Change Controller: IESG	Change Controller: IESG

	</t>	</li>
	<t>	<li>
	Specification Document(s): <xref target="SymmetricPoP"/> of [[ t	Specification Document(s): <xref target="SymmetricPoP"
	his document ]]	format="default"/> of RFC 8747
	</t>	</li>
	</list>	</ul>
	</t>	<ul spacing="compact">
	<t>	<li>
	<list style='symbols'>	Confirmation Method Name: <tt>kid</tt>
	<t>	</li>
	Confirmation Method Name: <spanx style="verb">kid</spanx>	<li>
	</t>
	<t>
	Confirmation Method Description: Key Identifier	Confirmation Method Description: Key Identifier

	</t>	</li>
	<t>	<li>
	JWT Confirmation Method Name: <spanx style="verb">kid</spanx>	JWT Confirmation Method Name: <tt>kid</tt>
	</t>	</li>
	<t>	<li>
	Confirmation Key: 3	Confirmation Key: 3
	</t>	</li>
	<t>	<li>
	Confirmation Value Type(s): binary string	Confirmation Value Type(s): binary string
	</t>	</li>
	<t>	<li>
	Change Controller: IESG
	</t>
	<t>
	Specification Document(s): <xref target="KidPoP"/> of [[ this do
	cument ]]
	</t>
	</list>
	</t>
	<!--
	<t>
	<list style='symbols'>
	<t>
	Confirmation Method Name: <spanx style="verb">jku</spanx>
	</t>
	<t>
	Confirmation Method Description: JWK Set URL
	</t>
	<t>
	JWT Confirmation Method Name: <spanx style="verb">jku</spanx>
	</t>
	<t>
	Confirmation Key: TBD
	</t>
	<t>
	Confirmation Value Type(s): text string
	</t>
	<t>
	Change Controller: IESG	Change Controller: IESG

	</t>	</li>
	<t>	<li>
	Specification Document(s): <xref target="jkuPoP"/> of [[ this do	Specification Document(s): <xref target="KidPoP"
	cument ]]	format="default"/> of RFC 8747
	</t>	</li>
	</list>	</ul>
	</t>
	</section>	</section>

	<?rfc subcompact="no"?>
	</section>	</section>


	</section>	</section>


	</middle>	</middle>


	<back>	<back>

	<references title="Normative References">	<displayreference target="I-D.ietf-ace-oauth-authz" to="ACE-OAUTH"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<displayreference target="RFC7515" to="JWS"/>
	FC.2119.xml' ?>	<displayreference target="RFC7519" to="JWT"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references>
	FC.7049.xml' ?>	<name>References</name>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references>
	FC.8126.xml' ?>	<name>Normative References</name>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8152.xml' ?>	FC.2119.xml"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8174.xml' ?>	FC.7049.xml"/>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8392.xml' ?>	FC.8126.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<reference anchor="IANA.CWT.Claims" target="http://www.iana.org/assignment	FC.8152.xml"/>
	s/cwt">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>	FC.8174.xml"/>
	<title>CBOR Web Token Claims</title>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author>	FC.8392.xml"/>
	<organization>IANA</organization>	<reference anchor="IANA.CWT.Claims" target="http://www.iana.org/assignme
	</author>	nts/cwt">
	<date/>	<front>
	</front>	<title>CBOR Web Token Claims</title>
	</reference>	<author>
		<organization>IANA</organization>
	</references>	</author>
		<date/>
	<references title="Informative References">	</front>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	</reference>
	FC.8259.xml' ?>	</references>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<references>
	FC.7800.xml' ?>	<name>Informative References</name>
	<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	FC.8610.xml' ?>	FC.8259.xml"/>
	<reference anchor="JWS" target="http://www.rfc-editor.org/info/rfc7515">	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>	FC.7800.xml"/>
	<title>JSON Web Signature (JWS)</title>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">	FC.8610.xml"/>
	<organization>Microsoft</organization>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<address>	FC.7515.xml"/>
	<email>mbj@microsoft.com</email>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<uri>http://self-issued.info/</uri>	FC.7519.xml"/>
	</address>
	</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization abbrev="Ping Identity">Ping Identity</organization>
	<address>
	<email>ve7jtb@ve7jtb.com</email>
	</address>
	</author>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization abbrev="NRI">Nomura Research Institute</organization>
	<address>
	<email>n-sakimura@nri.co.jp</email>
	</address>
	</author>
	<date month="May" year="2015"/>
	</front>
	<seriesInfo name="RFC" value="7515" />
	<seriesInfo name="DOI" value="10.17487/RFC7515"/>
	</reference>

	<reference anchor="JWT" target='http://www.rfc-editor.org/info/rfc7519'>
	<front>
	<title>JSON Web Token (JWT)</title>
	<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
	<organization>Microsoft</organization>
	<address>
	<email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
	</address>
	</author>
	<author fullname="John Bradley" initials="J." surname="Bradley">
	<organization abbrev="Ping Identity">Ping Identity</organization>
	<address>
	<email>ve7jtb@ve7jtb.com</email>
	</address>
	</author>
	<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
	<organization abbrev="NRI">Nomura Research Institute</organization>
	<address>
	<email>n-sakimura@nri.co.jp</email>
	</address>
	</author>
	<date month="May" year="2015"/>
	</front>
	<seriesInfo name="RFC" value="7519"/>
	<seriesInfo name="DOI" value="10.17487/RFC7519"/>
	</reference>

	<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/refer
	ence.OASIS.saml-core-2.0-os.xml' ?> -->


	<reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-open.	<reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-open.
	org/security/saml/v2.0/">	org/security/saml/v2.0/saml-core-2.0-os.pdf">
	<front>	<front>
	<title>Assertions and Protocol for the OASIS Security Assertion Markup	<title>Assertions and Protocol for the OASIS Security Assertion Mark
	Language	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">
	<organization>Nokia</organization>	<organization>Nokia</organization>
	<address>	<address>
	<email>John.Kemp@nokia.com</email>	<email>John.Kemp@nokia.com</email>
	</address>	</address>
	</author>	</author>
	<author fullname="Rob Philpott" initials="R." surname="Philpott">	<author fullname="Rob Philpott" initials="R." surname="Philpott">
	<organization>RSA Security</organization>	<organization>RSA Security</organization>
	<address>	<address>
	<email>rphilpott@rsasecurity.com</email>	<email>rphilpott@rsasecurity.com</email>
	</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"/>
	<format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/	</reference>
	saml-core-2.0-os.pdf"/>	<reference anchor="IANA.JWT" target="http://www.iana.org/assignments/jwt
	</reference>	">
		<front>
	<reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignment	<title>JSON Web Token (JWT)</title>
	s/jwt">	<author>
	<front>	<organization>IANA</organization>
	<title>JSON Web Token Claims</title>	</author>
	<author>	<date/>
	<organization>IANA</organization>	</front>
	</author>	</reference>
	<date/>
	</front>
	</reference>

	<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.
	I-D.draft-ietf-ace-oauth-authz-21"?>


		<xi:include href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.
		draft-ietf-ace-oauth-authz-21.xml"/>
		</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
	<section title='Acknowledgements' anchor='Acknowledgements' numbered="no">	<name>Acknowledgements</name>
	<t>	<t>
	Thanks to the following people for their reviews of the specification:	Thanks to the following people for their reviews of the specification:

	Roman Danyliw,	<contact fullname="Roman Danyliw"/>,
	Christer Holmberg,	<contact fullname="Christer Holmberg"/>,
	Benjamin Kaduk,	<contact fullname="Benjamin Kaduk"/>,
	Mirja Kühlewind,	<contact fullname="Mirja Kühlewind"/>,
	Yoav Nir,	<contact fullname="Yoav Nir"/>,
	Michael Richardson,	<contact fullname="Michael Richardson"/>,
	Adam Roach,	<contact fullname="Adam Roach"/>,
	Éric Vyncke,	<contact fullname="Éric Vyncke"/>,
	and	and

	Jim Schaad.	<contact fullname="Jim Schaad"/>.
	</t>	</t>

	<t>Ludwig Seitz and Göran Selander worked on this document as part of	<t><contact fullname="Ludwig Seitz"/> and <contact fullname="Göran
		Selander"/> 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>


	<section title="Document History" anchor="History">
	<t>
	[[ to be removed by the RFC Editor before publication as an RFC ]]
	</t>

	<t>-11
	<list style='symbols'>
	<t>
	Addressed remaining IESG review comment by Mirja Kühlewind.
	</t>
	</list>
	</t>

	<t>-10
	<list style='symbols'>
	<t>
	Addressed IESG review comments by Adam Roach and Éric Vyncke.
	</t>
	</list>
	</t>

	<t>-09
	<list style='symbols'>
	<t>
	Addressed Gen-ART review comments by Christer Holmberg and
	SecDir review comments by Yoav Nir.
	</t>
	</list>
	</t>

	<t>-08
	<list style='symbols'>
	<t>
	Addressed remaining Area Director review comments by Benjamin Kaduk.
	</t>
	</list>
	</t>

	<t>-07
	<list style='symbols'>
	<t>
	Addressed Area Director review by Benjamin Kaduk.
	</t>
	</list>
	</t>

	<t>
	-06
	<list style='symbols'>
	<t>
	Corrected nits identified by Roman Danyliw.
	</t>
	</list>
	</t>

	<t>
	-05
	<list style='symbols'>
	<t>
	Added text suggested by Jim Schaad describing considerations when usin
	g the Key ID confirmation method.
	</t>
	</list>
	</t>

	<t>
	-04
	<list style='symbols'>
	<t>
	Addressed additional WGLC comments by Jim Schaad and Roman Danyliw.
	</t>
	</list>
	</t>

	<t>
	-03
	<list style='symbols'>
	<t>
	Addressed review comments by Jim Schaad, see https://www.ietf.org/mai
	l-archive/web/ace/current/msg02798.html
	</t>
	<t>
	Removed unnecessary sentence in the introduction regarding the use an
	y strings that could be case-sensitive.
	</t>
	<t>
	Clarified the terms Presenter and Recipient.
	</t>
	<t>
	Clarified text about the confirmation claim.
	</t>
	</list>
	</t>

	<t>
	-02
	<list style='symbols'>
	<t>
	Changed "typically" to "often" when describing ways of performing pro
	of of possession.
	</t>
	<t>
	Changed b64 to hex encoding in an example.
	</t>
	<t>
	Changed to using the RFC 8174 boilerplate instead of the RFC 2119 boi
	lerplate.
	</t>
	</list>
	</t>

	<t>
	-01
	<list style='symbols'>
	<t>
	Now uses CBOR diagnostic notation for the examples.
	</t>
	<t>
	Added a table summarizing the "cnf" names, keys, and value types.
	</t>
	<t>
	Addressed some of Jim Schaad's feedback on -00.
	</t>
	</list>
	</t>

	<t>
	-00
	<list style='symbols'>
	<t>
	Created the initial working group draft from draft-jones-ace-cwt-proo
	f-of-possession-01.
	</t>
	</list>
	</t>

	</section>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 134 change blocks.
	862 lines changed or deleted	572 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/