Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <2fff93e711e621960abe362cebd58b16a2080b6c.camel@redhat.com>
Date: Wed, 5 Nov 2025 10:05:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F38BEF8-F635-4001-A594-F9648139A85A@alkaline-solutions.com>
References: 
 <176230476293.658394.8309587942982495635@dt-datatracker-5df8666cb-7l4w5>
 <2fff93e711e621960abe362cebd58b16a2080b6c.camel@redhat.com>
To: Simo Sorce <simo=40redhat.com@dmarc.ietf.org>
Message-ID-Hash: Q56TN47W5HV36R3H4E26RNKW5ULTML7N
CC: jose@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bjose=5D_Re=3A_I-D_Action=3A_draft-ietf-jose-json-web-proof-12?=
	=?utf-8?q?=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/jose/eIpmWyDwJZQaSUmAonrY__g9FSM>

Hello Simo!

The expectation is that within a particular application, one or the =
other would be chosen. As such, implementors also would be expected for =
the most part to target one or the other as mandated by the application =
domain. I think it would be appropriate adding text to that effect.

The JOSE WG is chartered to create CBOR representations of JWP and JPT, =
and to leverage COSE and CWT where feasible. The changes in the scope of =
these documents largely come to different header data serialization for =
CBOR-encoded JWP, different payload data serialization when creating =
CPT, and media types to distinguish JSON from CBOR. Several headers also =
have slightly different representations (but the same semantics) under =
the assumption of leveraging JOSE vs COSE infrastructure.

Editorially, the decision was made to keep JSON and CBOR in the same =
documents to better illustrate when there are differences and to =
simplify creation of common registries, but also as a conscious choice =
to not represent CBOR serialization as being a secondary or lesser goal =
when the work is being done under JOSE rather than COSE.

-DW

> On Nov 5, 2025, at 8:05=E2=80=AFAM, Simo Sorce =
<simo=3D40redhat.com@dmarc.ietf.org> wrote:
>=20
> FWIW as an implementer of the JOSE suite of algorithms and protocols I
> am *not* in favor of adding a binary serialization (CBOR) to JOSE, as
> it is completely antithetical to the rest of the specification and
> would force implementations to add a completely new and complex =
parsing
> and serialization subsystem that is fundamentally different from the
> rest of the protocol.
>=20
> On Tue, 2025-11-04 at 17:06 -0800, internet-drafts@ietf.org wrote:
>> Internet-Draft draft-ietf-jose-json-web-proof-12.txt is now =
available. It is a
>> work item of the Javascript Object Signing and Encryption (JOSE) WG =
of the
>> IETF.
>>=20
>>   Title:   JSON Web Proof
>>   Authors: David Waite
>>            Michael B. Jones
>>            Jeremie Miller
>>   Name:    draft-ietf-jose-json-web-proof-12.txt
>>   Pages:   33
>>   Dates:   2025-11-04
>>=20
>> Abstract:
>>=20
>>   The JOSE set of standards established JSON-based container formats
>>   for Keys, Signatures, and Encryption.  They also established IANA
>>   registries to enable the algorithms and representations used for =
them
>>   to be extended.  Since those were created, newer cryptographic
>>   algorithms that support selective disclosure and unlinkability have
>>   matured and started seeing early market adoption.  The COSE set of
>>   standards likewise does this for CBOR-based containers, focusing on
>>   the needs of environments which are better served using CBOR, such =
as
>>   constrained devices and networks.
>>=20
>>   This document defines a new container format similar in purpose and
>>   design to JSON Web Signature (JWS) and COSE Signed Messages called =
a
>>   _JSON Web Proof (JWP)_.  Unlike JWS, which integrity-protects only =
a
>>   single payload, JWP can integrity-protect multiple payloads in one
>>   message.  It also specifies a new presentation form that supports
>>   selective disclosure of individual payloads, enables additional =
proof
>>   computation, and adds a Presentation Header to prevent replay.
>>=20
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
>>=20
>> There is also an HTML version available at:
>> =
https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-12.html
>>=20
>> A diff from the previous version is available at:
>> =
https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-jose-json-web-proof=
-12
>>=20
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>=20
>>=20
>> _______________________________________________
>> jose mailing list -- jose@ietf.org
>> To unsubscribe send an email to jose-leave@ietf.org
>=20
> --=20
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
>=20
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org