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

<front>
<title abbrev="sd-cwt">Selective Disclosure CWTs (SD-CWT)</title><seriesInfo value="draft-prorock-cose-sd-cwt-00" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="M." surname="Prorock" fullname="Michael Prorock"><organization>mesur.io</organization><address><postal><street></street>
</postal><email>mprorock@mesur.io</email>
</address></author><author initials="O." surname="Steele" fullname="Orie Steele"><organization>Transmute</organization><address><postal><street></street>
</postal><email>orie@transmute.industries</email>
</address></author><date/>
<area>Internet</area>
<workgroup>None</workgroup>
<keyword>COSE</keyword>
<keyword>CWT</keyword>
<keyword>CBOR</keyword>
<keyword>SD</keyword>

<abstract>
<t>This document describes how to perform selective disclosure of claims
withing a CBOR Web Token (CWT) <xref target="RFC8392"></xref> as well as how to create and
verify those tokens.</t>
<t>This document does not define any new cryptography.</t>
</abstract>

</front>

<middle>

<section anchor="notational-conventions"><name>Notational Conventions</name>
<t>The key words &quot;<bcp14>MUST</bcp14>&quot;, &quot;<bcp14>MUST NOT</bcp14>&quot;, &quot;<bcp14>REQUIRED</bcp14>&quot;, &quot;<bcp14>SHALL</bcp14>&quot;, &quot;<bcp14>SHALL NOT</bcp14>&quot;, &quot;<bcp14>SHOULD</bcp14>&quot;,
&quot;<bcp14>SHOULD NOT</bcp14>&quot;, &quot;<bcp14>RECOMMENDED</bcp14>&quot;, &quot;<bcp14>MAY</bcp14>&quot;, and &quot;<bcp14>OPTIONAL</bcp14>&quot; in this
document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
</section>

<section anchor="terminology"><name>Terminology</name>
<t>The following terminology is used throughout this document:</t>

<dl spacing="compact">
<dt>signature</dt>
<dd>The digital signature output.</dd>
<dt>Claim Name</dt>
<dd>The human-readable name used to identify a claim.</dd>
<dt>Claim Key</dt>
<dd>The CBOR map key used to identify a claim.</dd>
<dt>Claim Value</dt>
<dd>The CBOR map value representing the value of the claim.</dd>
<dt>CWT Claims Set</dt>
<dd>The CBOR map that contains the claims conveyed by the CWT.</dd>
</dl>
</section>

<section anchor="selective-disclosure-of-claims-within-a-cwt"><name>Selective disclosure of claims within a CWT</name>

<section anchor="overview"><name>Overview</name>
<t>CBOR claims are cpommonly signed using <eref target="https://www.rfc-editor.org/rfc/rfc9052#section-4.2">COSE
Sign1</eref> where only
one signature is placed on a particular message.  There are many cases
where a signer may wish to ensure that the authenticity of a message has
not been compromised via a digital signature, but where they only wish
to reveal some values of the original signed message.  This document
outlines a precise method for formulating and transmitting these
messages, encompassing elements such as claims, claim keys, and
necessary data structures. This kind of signed information exchange
proves particularly beneficial in scenarios where a CBOR Web Token (CWT)
might transit via an intermediary before undergoing third-party
verification. Frequently, such a third party might necessitate, or be
permitted to access only a subset of the information encapsulated in the
CWT. This proposed model facilitates selective data disclosure, while
still preserving the ability to validate the original signature.</t>
<t>This representation relies on claims registered in the <eref target="https://www.iana.org/assignments/cwt/cwt.xhtml">IANA CBOR Web
Token (CWT) Claims Registry</eref>
whenever possible.</t>
</section>

<section anchor="flow-diagram"><name>Flow Diagram</name>
<t>Figure 1: SD-CWT Issuance and Presentation Flow</t>

<artwork>           +------------+
           |            |
           |   Issuer   |
           |            |
           +------------+
                 |
               Issues
               SD-CWT
                 |
                 v
           +------------+
           |            |
           |   Holder   |
           |            |
           +------------+
                 |
              Presents
               SD-CWT
                 |
                 v
           +-------------+
           |             |+
           |  Verifiers  ||+
           |             |||
           +-------------+||
            +-------------+|
             +-------------+
</artwork>
</section>

<section anchor="creating-an-sd-cwt"><name>Creating an SD-CWT</name>
<t>An SD-CWT is a CWT of the hash digests of the claim values with unique
random salts and other metadata. It MUST be digitally signed using the
issuer's private key.</t>

<artwork>SD-CWT-CLAIMS = (METADATA, CWT-CLAIMS)
SD-CWT = SD-CWT-CLAIMS | SIG(SD-CWT-CLAIMS, ISSUER-PRIV-KEY)
</artwork>
<t>CWT-CLAIMS is a simple object with claim names mapped to hash digests
over the claim values with unique random salts:</t>

<artwork>CWT-CLAIMS = (
    CLAIM-NAME: HASH(SALT | CLAIM-VALUE)
)*
</artwork>
<t>In a case where an SD-CWT is sent with all information disclose, the
SD-CWT is sent together with the mapping of the plain-text claim values,
the salt values, and potentially some other information. In this case,
the the payload contains the CWT-CLAIMS, and the field &quot;disclosures&quot;
contains the mapping, the salt values, and other metadata.</t>
<t>In a case where an SD-CWT is sent with only some information discosed,
only the desired claims, mappings, and salts are added to the
disclosure.</t>
<t>The CDDL fragment that represents the above text for COSE_Sign1 follows.</t>

<artwork>SD-CWT = [
    Headers,
    payload : bstr / nil,
    signature : bstr,
    disclosures: bstr / nil
]
</artwork>
</section>

<section anchor="verifying-an-sd-cwt"><name>Verifying an SD-CWT</name>
<t>TBD - Describe verifiacation process</t>
</section>

<section anchor="holder-binding-and-other-common-scenarios"><name>Holder Binding and other common scenarios</name>

<section anchor="holder-binding"><name>Holder Binding</name>
<t>TBD - Discuss optioinality, mechanism, and value</t>
</section>

<section anchor="counter-signatures"><name>Counter Signatures</name>
<t>TBD- Discuss use with countersignatures in the unprotected header</t>
</section>
</section>

<section anchor="data-structures"><name>Data Structures</name>
<t>TBD - Describe common data structures in CDDL</t>
</section>

<section anchor="examples"><name>Examples</name>
<t>TBD - Provide examples</t>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>All security considerations from COSE <xref target="RFC8152"></xref> and CWT <xref target="RFC8392"></xref>
SHOULD be followed.</t>
<t>To maintain the integrity of the issued claims, the Selective
Disclosure-CBOR Web Token (SD-CWT) MUST be signed by the issuer. Absence
of this signature leaves the SD-CWT vulnerable to attackers, who can
alter or append claims (for instance, modifying the &quot;email&quot; attribute to
hijack the victim's account or inserting a fabricated academic
qualification).</t>
<t>The verifier is required to verify the signature on the SD-CWT to
guarantee its authenticity and that no tampering has occurred post
issuance. If the signature on the SD-CWT fails the verification process,
the SD-CWT MUST be unequivocally rejected.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="media-type-registration"><name>Media Type Registration</name>
<t>This section will register the &quot;application/sd-cwt&quot; media type <xref target="RFC2046"></xref>
in the &quot;Media Types&quot; registry [IANA.MediaTypes] in the manner described
in RFC 6838 <xref target="RFC6838"></xref>, which can be used to indicate that the content is
a CWT.</t>

<ul spacing="compact">
<li>Type name: application</li>
<li>Subtype name: sd-cwt</li>
<li>Required parameters: n/a</li>
<li>Optional parameters: n/a</li>
<li>Encoding considerations: binary</li>
<li>Security considerations: See the Security Considerations section
of <xref target="RFC8392"></xref></li>
<li>Interoperability considerations: n/a</li>
<li>Published specification: This Specification</li>
<li>Applications that use this media type: mesur.io, transmute</li>
<li>Fragment identifier considerations: n/a</li>
<li>Additional information:
  Magic number(s): n/a
  File extension(s): n/a
  Macintosh file type code(s): n/a</li>
<li>Person &amp; email address to contact for further information:
Michael Prorock, mprorock@mesur.io</li>
<li>Intended usage: COMMON</li>
<li>Restrictions on usage: none</li>
<li>Author: Michael Prorock, mprorock@mesur.io</li>
<li>Change controller: IESG</li>
<li>Provisional registration?  Yes</li>
</ul>
</section>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors would like to thank those that have worked on similar items
for providing selective disclosure mechanisms in JSON, especially:
Tobias Looker, Kristina Yasuda, Daniel Fett, Oliver Terbu, and Michael
Jones.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
<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.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/>
</references>

</back>

</rfc>
