[jose] Re: I-D Action: draft-ietf-jose-json-web-proof-12.txt

[Simo Sorce <[e-mail]>]

Hi David,

Having both COSE and JOSE specifications in the same documents is also
problematic.

The last few documents I read are much harder to parse due to the focus
constantly shifting from one to the other. Not only it is harder for an
implementer that needs to implement only on or the other to follow the
document, it also risks conflating and confusing matters where the two
protocols differ.

I would strongly suggest paired documents instead where each only
discusses the either JOSE or COSE implementation requirements, but of
course with potential calls over to the other document for common
rationales. The registries are separate anyway so paired documents
would work well both for expert review and processing.

If paired documents are technically difficult I would urge to at least
organize documents with a common abstract, and then two completely
distinct sections, one for JOSE and one for COSE, so the implementer
can follow either one or the other branch according to what their
implementation domain is.

I am actively reading these documents and they are very tedious and
hard to parse having to constantly check if they are referencing JPT vs
CPT or sometimes both every other paragraph.

I really don't care about COSE and CBOR and these latest developments
make reading, interpreting and implementing these specifications for
the goal of implementing a JOSE library, much harder.

HTH,
Simo.

On Wed, 2025-11-05 at 10:05 -0700, David Waite wrote:
> 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 AM, Simo Sorce <simo=[e-mail]> wrote:
> > 
> > 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.
> > 
> > On Tue, 2025-11-04 at 17:06 -0800, [e-mail] 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.
> > > 
> > >   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
> > > 
> > > Abstract:
> > > 
> > >   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.
> > > 
> > >   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.
> > > 
> > > The IETF datatracker status page for this Internet-Draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
> > > 
> > > There is also an HTML version available at:
> > > https://www.ietf.org/archive/id/draft-ietf-jose-json-web-proof-12.html
> > > 
> > > A diff from the previous version is available at:
> > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-json-web-proof-12
> > > 
> > > Internet-Drafts are also available by rsync at:
> > > rsync.ietf.org::internet-drafts
> > > 
> > > 
> > > _______________________________________________
> > > jose mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > 
> > -- 
> > Simo Sorce
> > Distinguished Engineer
> > RHEL Crypto Team
> > Red Hat, Inc
> > 
> > _______________________________________________
> > jose mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc