W3C home > Mailing lists > Public > public-credentials@w3.org > November 2018

Switching to CBOR. Was: JSON-LD vs JWT for VC

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 2 Nov 2018 05:31:40 +0100
To: Manu Sporny <msporny@digitalbazaar.com>, public-credentials@w3.org
Message-ID: <e27caf0e-cbe7-1372-8b3a-6af30f582207@gmail.com>
IMO, switching from JSON to CBOR for the entire application is a
more logical path than base64-ing certain cryptographic constructs
(in order to maintain JSON compatibility) expressed in COSE.

The argument for (in some way) "hiding" algorithms and PUBLIC keys from
developers seems like a rather strange idea.  One of the motivations
behind https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01
was actually the opposite!


On 2018-11-01 16:13, Manu Sporny wrote:
> On 11/1/18 2:00 AM, Anders Rundgren wrote:
>> What's the rationale for that? Will WebPayments take this route as
>> well?
> The W3C Web Payments work does not include any standards-track digital
> signatures specifications AFAIK. There is no security at that layer
> other than the browser and TLS, although there is interest in adopting
> payment tokens/tokenization, which follows technical specifications
> created by EMVCo. That is an area that is politically fraught, so I
> hesitate to say any more about that... other than it's neither JOSE or COSE.
> The W3C Web Authentication work started with the JOSE stack and has
> since switched to the COSE stack. Moving Linked Data Proofs/Signatures
> to use COSE would bring us in line with the Web Authentication work,
> which does a number of digital signature operations.
> Many of the newer Web of Things and Internet of Things specifications
> are adopting CBOR as a compact representation format. This addresses a
> number of the "wasteful base-encoding when expressing stuff in JSON"
> arguments the low level protocol folks have of JOSE/JSON.
> Some in the group also believe that JOSE exposes cryptographic details
> that should not be exposed to web developers (things like x and y values
> of elliptic keys, for example). COSE wraps these in a binary blob that
> places it out of the purview of web developers, which is viewed as an
> advantage of COSE.
> Some also argue that COSE has an easier to analyze security surface vs.
> the JOSE stack, which means we can expect more thorough security
> analysis on that stack vs. the JOSE stack.
> CBOR encoding keys and signature/proof values also enables some of the
> more verbose proof formats like Sovrin's CL Signatures and Tierion's
> Chainpoint proofs to be encoded as "equal citizens" to all the other
> signature and proof formats we have. Web developers won't know the
> difference, nor care... they just shove it through a verification
> library and get a result.
> We are also working with Protocol Labs on how to use their multibase and
> multihash specs with COSE to provide some level of self-describing data
> formats.
> There are downsides for COSE, namely that library support isn't as
> mature as JOSE and that there are some aspects of CBOR that are not
> fully fleshed out in implementations yet. I've been in touch with Jim
> Schaad (primary editor of COSE) and with folks from the FIDO Alliance /
> Web Authentication WG asking them about horror stories or other concerns
> wrt. COSE and have not heard of any beside the general categories I
> mention above.
> It seems like the industry direction for digital signatures is COSE and
> as such, it provides an opportunity for all of the various camps to
> converge toward that. I haven't heard vehement objection to this
> direction yet (unlike the other options that have been considered for
> years).
> -- manu
Received on Friday, 2 November 2018 04:32:09 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:50 UTC