<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-lemmons-composite-claims-01" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="Composite Token Claims">Composite Token Claims</title><seriesInfo value="draft-lemmons-composite-claims-01" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="C." surname="Lemmons" fullname="Chris Lemmons"><organization>Comcast</organization><address><postal><street></street>
</postal><email>chris_lemmons@comcast.com</email>
</address></author><date/>
<area>Security</area>
<workgroup>TBD WG</workgroup>

<abstract>
<t>Composition claims are CBOR Web Token claims that define logical relationships
between sets of claims and provide for private claim values via encryption.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>Composition claims are claims defined for CBOR Web Tokens (CWTs) <xref target="RFC7519"></xref>.
These claims include logical operators &quot;or&quot;, &quot;nor&quot;, and &quot;and&quot; as well as a
wrapper that encrypts the values, but not the keys, of some claims.</t>
</section>

<section anchor="terminology"><name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,
and only when, they appear in all capitals, as shown here.</t>
<t>This document reuses terminology from CWT <xref target="RFC7519"></xref> and COSE <xref target="RFC9052"></xref>.</t>
<t>This term is defined by this specification:</t>

<dl spacing="compact">
<dt>Composition Claim</dt>
<dd>A composition claim is a CWT claim that contains, as part of its value, one
or more CWT claim sets.</dd>
</dl>
</section>

<section anchor="claims"><name>Claims</name>
<t>Composition claims identify claim sets and define how the acceptability of the
claim sets affects the acceptability of the composition claim.</t>
<t>In CWTs without composition claims, there is exactly one set of claims, so the
acceptability of the claim set decides the acceptability of the CWT. However,
this document defines multiple sets of claims, so it instead refers to
accepting or rejecting claim sets. If the primary claim set is unacceptable,
the CWT is unacceptable and <bcp14>MUST</bcp14> be rejected.</t>
<t>Composition claims can be nested to an arbitrary level of depth.
Implementations <bcp14>MAY</bcp14> limit the depth of composition nesting by rejecting
CWTs with too many levels but <bcp14>MUST</bcp14> support at least four levels of nesting.</t>

<section anchor="logical-claims"><name>Logical Claims</name>
<t>These claims allow multiple claim sets to be evaluated. This claim identifies
one or more sets of claims in a logical relation. The type of these claims is
array and the elements of the array are maps that are themselves sets of
claims.</t>

<section anchor="or-or-claim"><name>or (Or) Claim</name>
<t>The &quot;or&quot; (Or) claim identifies one or more sets of claims of which at least one
is valid. If every set of claims in an &quot;or&quot; claim would, when considered with
all the other relevant claims, result in the claim set being rejected, the
claim set containing the &quot;or&quot; claim <bcp14>MUST</bcp14> be rejected.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>. The Claim Key [add key number] is used to
identify this claim.</t>
</section>

<section anchor="nor-not-or-claim"><name>nor (Not Or) Claim</name>
<t>The &quot;nor&quot; (Nor) claim identifies one or more sets of claims of which none are
valid. If any set of claims in a &quot;nor&quot; claim would, when considered with all
other relevant claims, result in the claim set being accepted, the claim set
containing the &quot;nor&quot; <bcp14>MUST</bcp14> be rejected.</t>
<t>This is the logical negation of the &quot;or&quot; claim.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>. The Claim Key [add key number] is used to
identify this claim.</t>
</section>

<section anchor="and-and-claim"><name>and (And) Claim</name>
<t>The &quot;and&quot; (And) claim idenfies one or more sets of claims of which all are
valid. If any claim in an &quot;and&quot; claim would, when considered with all other
relevant claims, result in the claim set being rejected, the claim set
containing the &quot;and&quot; claim <bcp14>MUST</bcp14> be rejected.</t>
<t>The &quot;and&quot; claim is often unnecessary because a given claim set is only accepted
when all its claims are acceptable. However, CBOR maps cannot have duplicate
keys, so claims cannot be repeated more than once. The &quot;and&quot; claim is useful
for claims that may be claimed multiple times, including the &quot;or&quot; and &quot;nor&quot;
claims.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>. The Claim Key [add key number] is used to
identify this claim.</t>
</section>
</section>

<section anchor="enveloped-claims"><name>Enveloped Claims</name>
<t>Eveloped claims identify a set of claims that should be considered as part of a
set of claims, but that require decryption before they can be processed. This
is sometimes useful when some processors do not need to evaluate some claims in
order to determine if a claim set is acceptable.</t>

<section anchor="env-enveloped-claim"><name>env (Enveloped) Claim</name>
<t>The &quot;env&quot; (Enveloped) claim allows an issuer to make private claims that cannot
be read by a processor that does not possess the decryption key. The type of
this claim is a map; the keys of the map are either claim keys (string,
unsigned integer, or negative integer) or arrays of claim keys; the values of
the map are COSE_Encrypt or COSE_Encrypt0 objects, as defined by
<xref target="RFC9052" sectionFormat="of" relative="#" section="5"></xref>. The plaintext of the Enveloped Message is either a CBOR
data item or a CBOR array of data items.</t>
<t>Each element of the map is interpreted as follows:</t>

<ul spacing="compact">
<li>If the key is a claim key, the plaintext of the Enveloped Message in its
value is a CBOR data item that is appropriate as a value for that claim.</li>
<li>If the key is an array of claim keys, the plaintext of the Enveloped
Message in its value is an array with the cardinality equal to or larger
than the array of claim keys. Each member of the array in the plaintext
corresponds with the member in the array in the key with the same index.
Elements of the value array with indexes that do not correspond with
elements of the key array MUST be ignored. The members of the array in the
plaintext are CBOR data items that are appropriate as values for the
corresponding claim.</li>
</ul>
<t>These claims described in the &quot;env&quot; claim <bcp14>MAY</bcp14> be processed exactly as
though the &quot;env&quot; claim were replaced with the decrypted claims, including the
limitation that a map of claims is invalid if it contains a claim more than
once. The &quot;env&quot; claim is removed from the map before looking for duplicates, so
an &quot;env&quot; claim that contains an &quot;env&quot; claim may potentially be accepted. An
invalid claim set <bcp14>MUST</bcp14> be rejected. A claim set that contains
duplicate claims <bcp14>MUST</bcp14> be rejected, even if the duplicates are not
decrypted.</t>
<t>Since claims are optionally decrypted and added as sibling claims, issuers can
ensure that this occurs by adding them to the &quot;crit&quot; claim.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>. The Claim Key [add key number] is used to
identify this claim.</t>
</section>

<section anchor="crit-critical-claim"><name>crit (Critical) Claim</name>
<t>The &quot;crit&quot; (Critical) claim lists the claims required to process this token.</t>
<t>The type of this claim is array and the elements of the array are strings,
negative integers, or unsigned integers. The elements of the array correspond
to claims that may be present in the token.</t>
<t>If a claim listed in the &quot;crit&quot; claim is present in a claim set and the
processor cannot understand or process the claim, the claim set <bcp14>MUST</bcp14> be
rejected.</t>
<t>If a claim listed in the &quot;crit&quot; claim is not present in a claim set, the claim
set <bcp14>MUST</bcp14> be rejected.</t>
<t>If a claim listed in the &quot;crit&quot; claim is present in a claim set as part of a
&quot;env&quot; claim (and, should it be decrypted, be processed as a sibling of that
&quot;env&quot; claim), if the value of the claim is not decrypted (for any reason) and
processed and any possible value of the claim would result in the request being
rejected, the claim set <bcp14>MUST</bcp14> be rejected. Since any processor <bcp14>MAY</bcp14>
decrypt or not decrypt claim values in a &quot;env&quot; claim, this means a processor
<bcp14>MAY</bcp14> reject any claim set that contains a claim that could have a value that
would require rejection.</t>
<t>If a &quot;crit&quot; claim is present in a claim set, a processor <bcp14>SHOULD</bcp14> consider
claims it does not understand to be acceptable if they are not present in the
&quot;crit&quot; claim. That is, when a &quot;crit&quot; claim is present, any claims not listed
may be assumed to be non-critical.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>. The Claim Key [add key number] is used to
identify this claim.</t>
</section>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>All security considerations relevant to CWTs in general will apply to CWTs that
use composition claims.</t>
<t>Additionally, processors of CWTs with composition claims will need to be aware
of the possibility of receiving highly nested tokens. Excessive nesting can
lead to overflows or other processing errors.</t>
<t>The security of the &quot;env&quot; claim is subject to all the considerations detailed
for COSE objects in <xref target="RFC9052" sectionFormat="of" relative="#" section="12"></xref>. Particular attention is required
to length attacks. If the length of the Enveloped Claims is revealing as to its
contents, as it most often will be in this context, issuers MUST pad the
content appropriately in order to maintain the secrecy of its contents. &quot;env&quot;
claims permit additional elements to be added after arrays of claim keys that
can be used for padding when it is required.</t>
<t>Additionally, since the &quot;env&quot; claim only encrypts the contents of the claim and
not its key, it discloses the presence of a given claim. When this is
undesirable, another composite claim like &quot;and&quot;, &quot;or&quot;, or even potentially
&quot;env&quot; can be be used to mask the presence of the claim within.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>[When claims keys have been identified and selected, this section will ask IANA
to register those keys.]</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>
</references>

</back>

</rfc>
