Much of what Simo says really resonates. I know CBOR/COSE/CWT made it into the latest charter but I think there is still a very sizable contingent of stakeholders (application and library developers, dependent specification editors, etc.) in the JOSE sphere that expect JOSE-style JSON work from documents called JSON Web Proof, JSON Proof Token, and JSON Proof Algorithms from the JSON Object Signing and Encryption Working Group that at least conceptually build on the previously published RFCs of JSON Web Signature, JSON Web Encryption, JSON Web Key, and JSON Web Token.
Forcing COSE and JOSE together in the same document is (almost) always a disservice to all involved. On Wed, Nov 5, 2025 at 1:38 PM Simo Sorce <[email protected]> wrote: > 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= > [email protected]> 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, [email protected] 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 -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > > > > -- > > > Simo Sorce > > > Distinguished Engineer > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > _______________________________________________ > > > jose mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
