<?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-cose-composite-claims-02" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true">

<front>
<title abbrev="Composite Token Claims">Composite Token Claims</title><seriesInfo value="draft-lemmons-cose-composite-claims-02" 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>COSE WG</workgroup>
<keyword>CBOR</keyword>
<keyword>CWT</keyword>
<keyword>COSE</keyword>
<keyword>JWT</keyword>
<keyword>JSON</keyword>

<abstract>
<t>Composition claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens
(JWTs) that define logical relationships between sets of claims.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>Composition claims are claims defined for CBOR Web Tokens (CWTs) <xref target="RFC8392"></xref>
and JSON Web Tokens (JWTs) <xref target="RFC7519"></xref>.</t>
<t>This document defines the CWT representations of the composition claims named
&quot;and&quot;, &quot;or&quot;, &quot;nor&quot;. It also defines a CWT definition for &quot;crit&quot;.</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="RFC8392"></xref>, JWT <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 claim whose value contains one or more claim sets.</dd>
<dt>Claim Set</dt>
<dd>A set of claims. For CWTs this is a CBOR map. For JWTs
this is a JSON object.</dd>
</dl>
</section>

<section anchor="claims"><name>Claims</name>
<t>Composition claims contain one or more claim sets.</t>
<t>In tokens without composition claims, there is exactly one set of claims, so
the acceptability of the claim set decides the acceptability of the token.
However, this document defines multiple claim sets, so it instead refers to
accepting or rejecting claim sets. If the primary claim set is unacceptable,
the token is unacceptable and <bcp14>MUST</bcp14> be rejected.</t>
<t>Some applications use tokens to convey information. For example, a token might
simply have a subject claim that identifies the bearer and the relying party
simply uses that as information, not necessarily as a means by which to provide
or deny access or make some other kind of decision. In this context, the token
simply describes all situations in which the token would accurately describe
that situation.</t>
<t>Composition claims may be nested arbitrarily. Implementations <bcp14>MAY</bcp14> reject
tokens exceeding an implementation-defined nesting depth but <bcp14>MUST</bcp14> support at
least four levels.</t>

<section anchor="logical-claims"><name>Logical Claims</name>
<t>These claims identify 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>
<t>In CWTs, the value is a CBOR array of CBOR maps. In JWTs, the value is a JSON
array of JSON objects.</t>
<t>For the following CDDL, <tt>Claims-Set</tt> is a map of claims as defined in
<xref target="RFC8392"></xref>. It is described informatively in <xref target="RFC9711"></xref>, Appendix D.</t>

<section anchor="or-or-claim"><name>or (Or) Claim</name>
<t>The &quot;or&quot; (Or) claim identifies one or more claim sets of which at least one is
acceptable. If none of the claim sets in an &quot;or&quot; claim is acceptable, the
claim set containing the &quot;or&quot; claim is also unacceptable.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>.</t>
<t>In JWTs, the Claim Name is &quot;or&quot; and the Claim Value is a JSON array of JSON
objects.</t>
<t>In CWTs, the Claim Key is TBD (to be registered in the &quot;CBOR Web Token (CWT)
Claims&quot; registry).</t>
<t>The &quot;or&quot; (Or) claim is described by the following CDDL:</t>

<sourcecode type="cddl"><![CDATA[$$Claims-Set-Claims //= ( or-claim-label => or-claim-value )
or-claim-label = TBD
or-claim-value = [ + Claims-Set ]
]]></sourcecode>
</section>

<section anchor="nor-not-or-claim"><name>nor (Not Or) Claim</name>
<t>The &quot;nor&quot; (Nor) claim identifies one or more claim sets of which none are
acceptable. If any claim set in a &quot;nor&quot; claim is acceptable, the claim set
containing the &quot;nor&quot; claim is also unacceptable.</t>
<t>This is the logical negation of the &quot;or&quot; claim.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>.</t>
<t>In JWTs, the Claim Name is &quot;nor&quot; and the Claim Value is a JSON array of JSON
objects.</t>
<t>In CWTs, the Claim Key is TBD (to be registered in the &quot;CBOR Web Token (CWT)
Claims&quot; registry).</t>
<t>The &quot;nor&quot; (Nor) claim is described by the following CDDL:</t>

<sourcecode type="cddl"><![CDATA[$$Claims-Set-Claims //= ( nor-claim-label => nor-claim-value )
nor-claim-label = TBD
nor-claim-value = [ + Claims-Set ]
]]></sourcecode>
</section>

<section anchor="and-and-claim"><name>and (And) Claim</name>
<t>The &quot;and&quot; (And) claim identifies one or more claim sets of which all are
acceptable. If any claim set in an &quot;and&quot; claim is not acceptable, the
claim set containing the &quot;and&quot; claim is also unacceptable.</t>
<t>The &quot;and&quot; claim is often unnecessary because a claim set is only accepted when
all its claims are acceptable. However, CBOR maps cannot have duplicate keys, so
claims cannot be repeated. The &quot;and&quot; claim is useful when a claim needs to
appear multiple times, like when using the &quot;or&quot; and &quot;nor&quot; claims.</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>.</t>
<t>In JWTs, the Claim Name is &quot;and&quot; and the Claim Value is a JSON array of JSON
objects.</t>
<t>In CWTs, the Claim Key is TBD (to be registered in the &quot;CBOR Web Token (CWT)
Claims&quot; registry).</t>
<t>The &quot;and&quot; (And) claim is described by the following CDDL:</t>

<sourcecode type="cddl"><![CDATA[$$Claims-Set-Claims //= ( and-claim-label => and-claim-value )
and-claim-label = TBD
and-claim-value = [ + Claims-Set ]
]]></sourcecode>
</section>

<section anchor="examples"><name>Examples</name>
<t>These logical claims can be used to describe more complex relationships between
claims. For example, the following claim set describes a token with multiple
subject claims. This token describes a situation where either of the two
subjects must be true, but the issuer is not disclosing which one must be true
or even whether the two subjects are genuinely different.</t>

<artwork><![CDATA[{
  /or/ TBD: [
    { /sub/ 2: "george@example.net" },
    { /sub/ 2: "harriet@example.net" }
  ]
}
]]></artwork>
<t>A relying party that receives this token knows that bearer claims to be both
George and Harriet and if either subject is acceptable, the token is
acceptable.</t>
<t>The following JWT claim set example is equivalent:</t>

<artwork><![CDATA[{
  "or": [
    { "sub": "george@example.net" },
    { "sub": "harriet@example.net" }
  ]
}
]]></artwork>
<t>The &quot;nor&quot; claim is useful both as a logical negation, even when only one claim
is present. For example, consider the following claim set:</t>

<artwork><![CDATA[{
  /nor/ TBD: [
    { /aud/ 3: "https://example.com" }
  ]
}
]]></artwork>
<t>This token is intended for any audience except &quot;example.com&quot;.</t>
<t>The following JWT claim set example is equivalent:</t>

<artwork><![CDATA[{
  "nor": [
    { "aud": "https://example.com" }
  ]
}
]]></artwork>
<t>Complex relationships can also be described using the claims in combination.
The &quot;geohash&quot; claim <xref target="CTA5009A"></xref> describes a geographical region. For example:</t>

<artwork><![CDATA[{
  /aud/ 3: "https://example.com",
  /geohash/ 282: "9q8yy",
  /nor/ TBD: [
    { /geohash/ 282: ["9q8yy9", "9q8yyd"] }
  ]
}
]]></artwork>
<t>This token describes an audience of &quot;<eref target="https://example.com&quot;">https://example.com"</eref> and a region
described by the geohash of &quot;9q8yy&quot; that does not include the region described
by &quot;9q8yy9&quot; or &quot;9q8yyd&quot;.</t>
<t>And if a very complex relationship is required, the &quot;and&quot; claim can be used to
combine multiple claims. For example, consider the following claim set:</t>

<artwork><![CDATA[{
  /and/ TBD: [
    {
      /or/ TBD: [
        { /sub/ 2: "george@example.net" },
        { /sub/ 2: "harriet@example.net" }
      ]
    },
    {
      /or/ TBD: [
        { /aud/ 3: "https://example.com" },
        { /aud/ 3: "https://example.net" }
      ]
    }
  ]
}
]]></artwork>
<t>This admittedly contrived example describes a token that is valid for both
George and Harriet and is intended for both <eref target="https://example.com">https://example.com</eref> and
<eref target="https://example.net">https://example.net</eref>. It is a bit contrived because the &quot;aud&quot; claim already
describes a list of acceptable audiences. The use of the &quot;and&quot; claim is
required in order to effectively repeat the &quot;or&quot; claim, because a single claim
set cannot contain the same claim twice.</t>
</section>
</section>

<section anchor="crit-critical-claim"><name>crit (Critical) Claim</name>
<t>The &quot;crit&quot; (Critical) claim indicates critical extensions to this kind of claim
set.</t>
<t>The semantics of the JWT claim name &quot;crit&quot; are defined by OpenID Federation 1.0
<xref target="OpenID-Federation"></xref>. This specification defines only the CWT representation.</t>
<t>The value of this claim is an array. Each element identifies a claim within the
same claim set.</t>
<t>In CWTs, elements are integers or text strings identifying claim keys. The
&quot;crit&quot; array <bcp14>MUST NOT</bcp14> be empty. Each element of the &quot;crit&quot; array <bcp14>MUST</bcp14>
identify a claim that is present in the same claim set. Elements in the &quot;crit&quot;
array <bcp14>MUST</bcp14> be unique.</t>
<t>Elements in the &quot;crit&quot; array <bcp14>MUST NOT</bcp14> identify claims that are specified
as MANDATORY to understand for the token. This will vary by application profile
as described in [RFC7519], Section 4. As noted in <xref target="OpenID-Federation"></xref>,
Section 13.4, any profile that requires correct processing of the &quot;crit&quot; claim
<bcp14>MUST</bcp14> of necessity specify that it is MANDATORY to understand.</t>
<t>If a claim listed in the &quot;crit&quot; claim is present in a claim set and the
processor cannot process the claim for any reason, the claim set <bcp14>MUST</bcp14> be
rejected. 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. (TODO: Square this with the OpenID
definition. The OpenID definition does not explicitly require claim sets to be
rejected if the claim name rules like including duplicates, empty arrays, or
the presence of claims that are not present in the claim set.)</t>
<t>Use of this claim is <bcp14>OPTIONAL</bcp14>.</t>
<t>In CWTs, the Claim Key is TBD (to be registered in the &quot;CBOR Web Token (CWT)
Claims&quot; registry).</t>

<section anchor="example"><name>Example</name>
<t>A &quot;crit&quot; claim can be used in conjunction with logical claims to condition a
portion of the token on the ability to process a claim:</t>

<artwork><![CDATA[{
  /or/ TBD: [
    { /geohash/ 282: "9q8y", /crit/ TBD: [ 282 ] },
    { /private/ -524289: "sf", /crit/ TBD: [ -524289 ] }
  ]
}
]]></artwork>
<t>This example assumes the existence of some kind of claim in the private space
that a relying party may or may not be able to process. This token claims that
the subject is in the described region and also that a private claim is present
and that the relying party must be able to verify at least one of those claims,
but it does not need to be able to process both.</t>
</section>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>All security considerations relevant to CWTs and JWTs in general will apply to
tokens that use composition claims.</t>
<t>Additionally, processors of tokens 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>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This specification requests that IANA register the following claim keys in the
&quot;CBOR Web Token (CWT) Claims&quot; registry established by <xref target="RFC8392"></xref>:</t>
<t>Claim Name: or<br />
Claim Description: Logical OR<br />
JWT Claim Name: or<br />
Claim Key: TBD<br />
Claim Value Type(s): array<br />
Change Controller: IESG</t>
<t>Claim Name: nor<br />
Claim Description: Logical NOR<br />
JWT Claim Name: nor<br />
Claim Key: TBD<br />
Claim Value Type(s): array<br />
Change Controller: IESG</t>
<t>Claim Name: and<br />
Claim Description: Logical AND<br />
JWT Claim Name: and<br />
Claim Key: TBD<br />
Claim Value Type(s): array<br />
Change Controller: IESG</t>
<t>Claim Name: crit<br />
Claim Description: Critical Claims<br />
JWT Claim Name: crit<br />
Claim Key: TBD<br />
Claim Value Type(s): array<br />
Change Controller: IESG</t>
<t>This specification requests that IANA register the following claim names in the
&quot;JSON Web Token Claims&quot; registry established by <xref target="RFC7519"></xref>:</t>
<t>Claim Name: or<br />
Claim Description: Logical OR<br />
Change Controller: IESG<br />
Specification Document(s): This document</t>
<t>Claim Name: nor<br />
Claim Description: Logical NOR<br />
Change Controller: IESG<br />
Specification Document(s): This document</t>
<t>Claim Name: and<br />
Claim Description: Logical AND<br />
Change Controller: IESG<br />
Specification Document(s): This document</t>
<t>The JWT Claim Name &quot;crit&quot; is already registered in the &quot;JSON Web Token Claims&quot;
registry and is defined by OpenID Federation 1.0 <xref target="OpenID-Federation"></xref>.</t>
</section>

</middle>

<back>
<references><name>References</name>
<references><name>Normative References</name>
<reference anchor="OpenID-Federation" target="https://openid.net/specs/openid-federation-1_0.html">
  <front>
    <title>OpenID Federation 1.0</title>
    <author>
      <organization>OpenID Foundation</organization>
    </author>
    <date></date>
  </front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="CTA5009A" target="https://shop.cta.tech/products/fast-and-readable-geographical-hashing-cta-5009">
  <front>
    <title>CTA 5009-A: Fast and Readable Geographical Hashing</title>
    <author>
      <organization>Consumer Technology Association</organization>
    </author>
    <date year="2024"></date>
  </front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9711.xml"/>
</references>
</references>

</back>

</rfc>
