Quoting Andres from a few messages back: >> BEGIN
The problem set is described, here is a short version: - Keeping signed JSON in JSON format - Enabling a consistent message structure regardless if messages are signed or not - Supporting signed JavaScript objects >>END 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 12:32 PM, Nat Sakimura <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]>> On Behalf >>> Of Anders Rundgren >>> Sent: Thursday, November 22, 2018 11:50 PM >>> To: [email protected] <mailto:[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- >>> <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] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/jose >>> <https://www.ietf.org/mailman/listinfo/jose> >> >> _______________________________________________ >> jose mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/jose >> <https://www.ietf.org/mailman/listinfo/jose> > > _______________________________________________ > jose mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose > <https://www.ietf.org/mailman/listinfo/jose> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ <http://nat.sakimura.org/> > @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
