I have need have having both parallel and nested signatures of JSON content.
Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > On Nov 23, 2018, at 10:37 AM, Jim Schaad <[email protected]> wrote: > > I am having a potential terminology problem. When I read the term Counter > Signature, I am used to this meaning that I am signing a signature, > potentially with some additional information. I am not sure that this is > what you have going on below. Are these signatures "nested" or "parallel" > or "on the previous signature"? > > Jim > > >> -----Original Message----- >> From: jose <[email protected]> On Behalf Of Anders Rundgren >> Sent: Thursday, November 22, 2018 11:50 PM >> To: [email protected] >> Subject: [jose] JWS Counter Signatures >> >> Counter signatures were actually the major "inspiration" for Canonical > JSON >> since JWS based dittos are hard to debug and document due to the deep >> nesting of Base64Url encoded objects but it is still fully doable. >> >> However, in a system which I will present at Trustech 2018, I came up with > a >> counter signature scheme where JOSE simply put ran out of gas. >> >> https://cyberphone.github.io/doc/payments/payment-decentralization-scheme- >> 1a.pdf >> >> In this system (very briefly): >> 1. a Merchant creates a Payment Request and sends it to the Payer for >> authorization 2. the Payer authorizes the Payment Request with his/her >> signature key. The signed authorization data includes a hash of the > Payment >> Request 3. the Payer (for privacy reasons) encrypts the authorization data > and >> returns it to the Merchant together with an unencrypted URL pointing to > the >> Payer's bank 4. the Merchant sends the original Payment Request + the >> encrypted Payer authorization data to the Payer's banks for fulfillment 5. > the >> Payer's bank decrypts and validates the authorization data, including > verifying >> that the hash of the Merchant-supplied Payment Request matches the hash in >> the authorization data >> >> It seems to me that a JOSE based design would have to be architected in a >> fundamentally different way. >> >> Anders >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
