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

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!

Anders


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