Spec updates: Linked Data Signatures

The Linked Data Signatures specification has been updated to be more
generalized. Here's what that means.

The digital signature algorithm has historically been tightly coupled
with the Linked Data Signatures specification. This means that we'd have
to revise the specification each time we wanted to update the signature
mechanism. That's a bad spec design. So, we've made the following changes:

Signature Suites
================

https://web-payments.org/specs/source/ld-signatures/#signature-suites

The concept of a "Signature Suite" was added to the specification. A
signature suite is a combination of canonicalization, message digest,
and digital signature algorithm. For example, "LinkedDataSignature2015"
is a Signature Suite that uses the URDNA2015 canonicalization algorithm,
the SHA-256 message digest algorithm, and the RSA-SHA256 signature
algorithm.

We had this concept before, but it's been documented in a way that
enables people to create their own Signature Suites.

Generalization of Signature Algorithm
=====================================

https://web-payments.org/specs/source/ld-signatures/#signature-suites

The Linked Data Signatures specification was simplified to generalize
the canonicalization algorithm, the message digest algorithm, and the
digital signature algorithm. This means that the signing and signature
verification algorithm can remain generic while the canonicalization
algorithm, message digest algorithm, and digital signature algorithm can
be changed and upgraded in a decentralized manner. People are now more
free to innovate on the sub algorithms without the need to change the
Linked Data Signatures spec (or interact with the communities working on
the spec).

Generalization of Verify Hash Algorithm
=======================================

https://web-payments.org/specs/source/ld-signatures/#create-verify-hash-algorithm

The verify hash algorithm has been generalized so that you can add
arbitrary attributes to the signature when you're doing the digital
signature. For example, if you wanted to include a proof of publication
to the digital signature, you can do so by just adding the appropriate
key-value pairs into the signature block now. That goes for any
signature-specific data, and by doing so, anything you dump into the
signature block will be signed as signature-specific information.

Refactoring Signature Suites Into Separate Specs
================================================

As a result of generalizing the above items, we were able to factor out
the signature suites from the core Linked Data specification.

The LinkedDataSignature2015 Signature Suite, which uses the older verify
hash algorithm, can now be found here:

https://web-payments.org/specs/source/lds2015/

The LinkedDataSignature2016 Signature Suite, which uses the new
generalized verify hash algorithm, can be found here:

https://web-payments.org/specs/source/lds2016/

The result of these updates is a more flexible signature format for
payment messages and verifiable claims. The likelihood of Linked Data
Signatures being picked up for payment messages in the next year or two
is very low. The likelihood of Linked Data Signatures being picked up
for verifiable claims is far higher. This approach also enables us to
provide JWT-based signatures, which may help us avoid some of the
controversies we've had with the JOSE community in the past.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Web Browser API Incubation Anti-Pattern
http://manu.sporny.org/2016/browser-api-incubation-antipattern/

Received on Wednesday, 4 May 2016 21:38:03 UTC