Hmmm. I am failing to understand the problem. In JWS: 1) you can have multiple signatures on the same hash: Parallel signature; as well as 2) you could encapsulate the signed blob into a new signature: Serial signature.
What is the problem? Nat On Sat, Nov 24, 2018 at 4:16 AM Bret Jordan <[email protected]> wrote: > 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 > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
