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/

mirror server hosted at Truenetwork, Russian Federation.