W3C home > Mailing lists > Public > public-credentials@w3.org > May 2017

Re: Progress on Linked Data Signatures from IETF 98

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Mon, 8 May 2017 17:13:07 +0200
To: Manu Sporny <msporny@digitalbazaar.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, "Stone, Matt" <matt.stone@pearson.com>
Cc: Credentials Community Group <public-credentials@w3.org>
Message-ID: <ff1bdf23-0509-1559-ea30-c88d78e4a19e@gmail.com>
On 2017-05-08 15:47, Manu Sporny wrote:
> ... If it /did/ end up being a blocker, we'd
> basically define a JSON canonicalization algorithm that recursively
> sorts all keys in lexicographical order and then serializes using no
> spaces/padding/etc.
> So, Anders, the canonicalization algorithm would basically be what
> you've been touting for a while now.

Well, I'm (after one of the JOSE guys pointed me to it...), rather advocating
JSON.stringify() using the ES6 specification which in a compliant JSON
implementation means "do nothing".  Yes, I'm super lazy :-)

 > On 05/08/2017 07:26 AM, Adrian Hope-Bailie wrote:
 >> Any progress on this?

 > Yes, I think we have a solution that seems to be drawing no objections
 > as of today.

IMO, mixing two designs with quite different roots seems less than ideal.
The solution certainly works but looks like a kludge to me.

I would consider using JWS detached undecoded signatures "as is" and scrap
"creator" and "RsaSignature2017".  The latter would then be replaced by a
crypto-neutral name like "RdfSignature2017".  That is, the only thing needed
specification-wise would be that "signatureValue" (which then would hold a
complete JWS object), must be extracted and deleted from the input data set
during validation.

Received on Monday, 8 May 2017 15:13:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:37 UTC