Subject: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

From: Anders Rundgren <[email-masked]>
Date: Sat, 8 Aug 2015 18:47:44 +0200

Hi JOSE WG,

The JOSE standards grew out of OpenID and similar.  They obviously do a great job in that space!

So the question I have tried to answer is: How do the JOSE standards fit in a more traditional XML or EDI context?

SIZE:
If we start with size (which probably is the least important factor here), JOSE signature schemes seem to have one thing in common: they need to Base64URL-encode protected header arguments which for X.509 certificates means two layers of Base64.  It doesn't take an Einstein to figure out that signatures schemes that use header protection for explicit X.509 data won't be particularly space-efficient.

READABILITY:
This is a more complicated issue than one might think because JSON unlike its "predecessors" does not depend on (or support) position-based data which for example makes the modified sample in JWS A.7

      {
       "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
       "protected":"eyJhbGciOiJFUzI1NiJ9",
       "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
       "header":  {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
      }

fully valid but slightly less pleasing to read.  Applied to JSON objects with dozens of properties this (IMO) becomes a debug and document hurdle also for systems that do not use signatures.

Now going back to readability which was one of the motives behind draft-jones-jose-jws-signing-input-options 00...

As far as I can tell, draft-jones-jose-jws-signing-input-options 00 doesn't really deal with signed JSON, it is rather a scheme for signing arbitrary UTF-8 data.  If you use this scheme for in-line signing of JSON data, readability would suffer due to 1) typical JSON serializers' inability maintaining "insertion order" 2) the code getting garbled by escape characters.

That protected headers are Base64URL-encoded is also a readability (and debug) impediment.

If you would like to use a JSON schema for input validation things become rather "hacky" since the signature and the data isn't in the same format.

In some applications (like the ones I work with...), there's also a disadvantage with embedding signatures since they change the structure of an object completely.   That signed PDFs is not about putting PDF data inside of a CMS blob is not a coincidence!

All those issues put together plus the fact that "predictable serialization" is absolutely trivial to implement and has legitimate uses outside of signatures makes me less convinced that the JOSE WG at this stage has a viable solution for payments and such.

However, that DOES NOT disqualify draft-jones-jose-jws-signing-input-options 00 as a possible extension to existing JOSE standards.  The detached version of the concept seems like a particularly useful thing!

So, I'm still counting on a new scheme for payments. Although the following JCS sample may look verbose, it is actually quite a bit more byte-efficient than current JOSE signature schemes. Readability? Not even "pretty-printing" breaks signatures.  Well, strings must of course not be folded...

{
   "@context": "http://xmlns.webpki.org/webpay/v1",
   "@qualifier": "ProviderGenericAuthRes",
   "paymentRequest":
     {
       "payee": "Demo Merchant",
       "amount": "94617.00",
       "currency": "USD",
       "referenceId": "#1000002",
       "dateTime": "2015-08-08T14:17:22Z",
       "softwareId": "WebPKI.org - Merchant",
       "softwareVersion": "1.00",
       "signature":
         {
           "algorithm": "RS256",
           "signerCertificate":
             {
               "issuer": "CN=Merchant Network Sub CA5,C=DE",
               "serialNumber": "1437034463499",
               "subject": "CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE"
             },
           "certificatePath":
             [
"MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxMDAwMDAwWhcNMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGODk2MzI1MRYwFAYDVQQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgwjGibfiCx8SOPyM-xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_ZCeC018fC6cg9Yqc-vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXgN_42kIJSANVwwKj6HhXZVnaHHQ4M-cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA0CRXYc-3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTKCIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvcNAQELBQADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W0xJxPo0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0-GTnVlXwCkMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3JX-PIZoV7V_q-wevUwAJfoeWF21EKgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu866Nuj9XmKorNmDAmrxN4tX64tzNIMnaoTXv6qifQal0hEVRlE7ONUNfY",
"MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJVUzEiMCAGA1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAwMDBaFw0yNTA3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4QZ5re1twR79TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs-MVfiuDFmhTSfULT52o_mv5Re76n0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0uPUwjncRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK-vlHc5cvg1zd_G3HEECgg-EYYXbwUppb-7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcGoe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8GA1UdEwEB_wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue00dJGqQ79jesnEIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi-a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCAgEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxBFmHyVxZBRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbpKsTeolNceOVB8XzKz9Ti3TmmDt9VA20aruGw-Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N9m44Us8L6FZbRNaPfkVIfKRBGgtMziDUyyXrb0PisuRkdFenmkoqfO2d6QVho6SuNUlXd_pGNklKaQfEP-A6vN4XK7JpYhwgmhvrxKUUC9nfx601olcIcUm3TpewUz5t-s2Kpv4EVCAet6vKqHDH4A4oI2hOPEWSzhjqumtJmPguNGVdeBbdgZrVEl3XbwsROqgYGGHLXURSRnySaIaUY-4Se8HgA-AHbn3MiK_pBz1Igj-mokjZILt51t6I77Qf_fTi9OJYBrAPkZozxUGN2RaQ6zPqPlIgrKQQwS_jTQg-z_QkctYP8V7w9__Z6Na8dCR9rBhoruBdKO1OPipT_qeqRVq3xzu-80MFDRNouegE4UoS8_KTMwfisCKssrKydA7IIACMKa6V3BtGKD6ML3LhnhgfGQSoCxVU4v5QZ6866TImLRSl-E8M8SdeIZ4MKRV-oKPouq6B0d-0mrHkCstTilfI"
             ],
           "value": "AYUvS4Nq7cuHz8zCoXh_-vOWYKchnAAUfROaDbU1nGv9cM3H0uZz-W6d8v51jlBGq0bt9yWDpyjmd9FFqHSqLEf1FNTGTObAEpQ2ar6Lgvwmer-HXhi3Y5Hng7MqMokOZeF_tsbfZTffXg96BvFVRzUr3qBeCYPNMH7q2pTV_4L57sj4QssJkRfG-KxT1nSkhSGCD1big2Vfr_93CC0cKuURSJup2AwK-A3BJ3ax5QlW4YA2KBRiaSf6X1jlJhCFQZf-oaj7bUIna7kWd_f0ab869Co4H4HoDvECoDKa-JHqNw-NOeUAxT0brMHyKJ_Nvq8LUuiAzic3CPqIJaJSHA"
         }
     },
   "cardType": "SuperCard",
   "cardReference": "************2109",
   "referenceId": "#164010",
   "dateTime": "2015-08-08T14:17:37Z",
   "softwareId": "WebPKI.org - Bank",
   "softwareVersion": "1.00",
   "signature":
     {
       "algorithm": "ES256",
       "signerCertificate":
         {
           "issuer": "CN=Payment Network Sub CA3,C=EU",
           "serialNumber": "1437034453652",
           "subject": "CN=mybank.com,2.5.4.5=#130434353031,C=FR"
         },
       "certificatePath":
         [
"MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDExEzARBgNVBAMTCm15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jBPfnNXhQo9QSGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A-y1DVC34oOF71EyPeAv74mxhjc3gElgo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUKNflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0EAwIFAANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1QoIzr8gH800AnBrdOtG9Xw9jI-Vb1ixyow0tA",
"MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJVUzEhMB8GA1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391eOhqzmBraQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNjMGEwDwYDVR0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJpVvUo_C4VyeTArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCSqGSIb3DQEBDQUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC-XfSed9PJYuR2slXij3w2DFmxYHmbSVH4dZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F-qLVUpdFwEww1POd8T0n02YouRDSi4HWUY003C9hB6ouTdfHaswR6-cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd32gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI-GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l_ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQjNDigESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqismyMWNgIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75UtgTx1-Jfp6B3Qyji8pDR_Ba3eUlz1BJhyFuC8cHL275S8zQ2jCyjnaMXZvm_EnZGpOcm4DZrPD3cujBc1E09LyujylglLiN_up0I_ImliqF0GIA1o-s3nk7F1QlTe-7HWsbTrPOocm3SHDmyJEOgz8ChftelxeQ5-2hhz5QURdmmUIPUrDBcK1I5Fopv2-SPmNipPkZ1o7Gz1Mbqzrg"
         ],
       "value": "bUZ2bjXVKQisr_RyYG1Ru0P263ft1LkmhLnBTg94AjYQ4YLXLdwImmcZUd6yzApCSARFZ6xOoYw_IuvvkBG_ug"
     }
}

thanx,
Anders R
https://mobilepki.org/jcs

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 04:33:39 +0000

You can represent unencoded header and payload values by using "b64":false and "header" rather than "protected" with the JWS JSON Serialization.

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Saturday, August 08, 2015 9:48 AM
To: [email-masked]
Subject: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

Hi JOSE WG,

SIZE:

READABILITY:

      {

{
   "@context": "https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fxmlns.webpki.org%2fwebpay%2fv1&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zRirh4Ml%2bLrdObxfyIKPEiT%2fWTV8EkvxaWPwafW0ong%3d",
   "@qualifier": "ProviderGenericAuthRes",
   "paymentRequest":
     {
       "payee": "Demo Merchant",
       "amount": "94617.00",
       "currency": "USD",
       "referenceId": "#1000002",
       "dateTime": "2015-08-08T14:17:22Z",
       "softwareId": "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXeU8QTmBGIvMxL%2fjTb1GKdtHSo%3d - Merchant",
       "softwareVersion": "1.00",
       "signature":
         {
           "algorithm": "RS256",
           "signerCertificate":
             {
               "issuer": "CN=Merchant Network Sub CA5,C=DE",
               "serialNumber": "1437034463499",
               "subject": "CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE"
             },
           "certificatePath":
             [
"MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxMDAwMDAwWhcNMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGODk2MzI1MRYwFAYDVQQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgwjGibfiCx8SOPyM-xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_ZCeC018fC6cg9Yqc-vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXgN_42kIJSANVwwKj6HhXZVnaHHQ4M-cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA0CRXYc-3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTKCIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvcNAQELBQADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W0xJxPo0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0-GTnVlXwCkMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3JX-PIZoV7V_q-wevUwAJfoeWF21E
 Kgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu866Nuj9XmKorNmDAmrxN4tX64tzNIMnaoTXv6qifQal0hEVRlE7ONUNfY",
"MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJVUzEiMCAGA1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAwMDBaFw0yNTA3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4QZ5re1twR79TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs-MVfiuDFmhTSfULT52o_mv5Re76n0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0uPUwjncRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK-vlHc5cvg1zd_G3HEECgg-EYYXbwUppb-7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcGoe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8GA1UdEwEB_wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue00dJGqQ79jesnEIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi-a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCAgEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxBFmHyVxZBRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbpKsTeolNceOVB8XzKz9Ti3TmmDt9VA20aruGw-Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N9m44Us8L6FZbRNaPfk
 VIfKRBGgtMziDUyyXrb0PisuRkdFenmkoqfO2d6QVho6SuNUlXd_pGNklKaQfEP-A6vN4XK7JpYhwgmhvrxKUUC9nfx601olcIcUm3TpewUz5t-s2Kpv4EVCAet6vKqHDH4A4oI2hOPEWSzhjqumtJmPguNGVdeBbdgZrVEl3XbwsROqgYGGHLXURSRnySaIaUY-4Se8HgA-AHbn3MiK_pBz1Igj-mokjZILt51t6I77Qf_fTi9OJYBrAPkZozxUGN2RaQ6zPqPlIgrKQQwS_jTQg-z_QkctYP8V7w9__Z6Na8dCR9rBhoruBdKO1OPipT_qeqRVq3xzu-80MFDRNouegE4UoS8_KTMwfisCKssrKydA7IIACMKa6V3BtGKD6ML3LhnhgfGQSoCxVU4v5QZ6866TImLRSl-E8M8SdeIZ4MKRV-oKPouq6B0d-0mrHkCstTilfI"
             ],
           "value": "AYUvS4Nq7cuHz8zCoXh_-vOWYKchnAAUfROaDbU1nGv9cM3H0uZz-W6d8v51jlBGq0bt9yWDpyjmd9FFqHSqLEf1FNTGTObAEpQ2ar6Lgvwmer-HXhi3Y5Hng7MqMokOZeF_tsbfZTffXg96BvFVRzUr3qBeCYPNMH7q2pTV_4L57sj4QssJkRfG-KxT1nSkhSGCD1big2Vfr_93CC0cKuURSJup2AwK-A3BJ3ax5QlW4YA2KBRiaSf6X1jlJhCFQZf-oaj7bUIna7kWd_f0ab869Co4H4HoDvECoDKa-JHqNw-NOeUAxT0brMHyKJ_Nvq8LUuiAzic3CPqIJaJSHA"
         }
     },
   "cardType": "SuperCard",
   "cardReference": "************2109",
   "referenceId": "#164010",
   "dateTime": "2015-08-08T14:17:37Z",
   "softwareId": "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXeU8QTmBGIvMxL%2fjTb1GKdtHSo%3d - Bank",
   "softwareVersion": "1.00",
   "signature":
     {
       "algorithm": "ES256",
       "signerCertificate":
         {
           "issuer": "CN=Payment Network Sub CA3,C=EU",
           "serialNumber": "1437034453652",
           "subject": "CN=mybank.com,2.5.4.5=#130434353031,C=FR"
         },
       "certificatePath":
         [
"MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDExEzARBgNVBAMTCm15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jBPfnNXhQo9QSGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A-y1DVC34oOF71EyPeAv74mxhjc3gElgo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUKNflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0EAwIFAANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1QoIzr8gH800AnBrdOtG9Xw9jI-Vb1ixyow0tA",
"MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJVUzEhMB8GA1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391eOhqzmBraQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNjMGEwDwYDVR0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJpVvUo_C4VyeTArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCSqGSIb3DQEBDQUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC-XfSed9PJYuR2slXij3w2DFmxYHmbSVH4dZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F-qLVUpdFwEww1POd8T0n02YouRDSi4HWUY003C9hB6ouTdfHaswR6-cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd32gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI-GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l_ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQjNDigESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqismyMWNgIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75UtgTx1-Jfp6B3Qyji8pDR_Ba3eU
 lz1BJhyFuC8cHL275S8zQ2jCyjnaMXZvm_EnZGpOcm4DZrPD3cujBc1E09LyujylglLiN_up0I_ImliqF0GIA1o-s3nk7F1QlTe-7HWsbTrPOocm3SHDmyJEOgz8ChftelxeQ5-2hhz5QURdmmUIPUrDBcK1I5Fopv2-SPmNipPkZ1o7Gz1Mbqzrg"
         ],
       "value": "bUZ2bjXVKQisr_RyYG1Ru0P263ft1LkmhLnBTg94AjYQ4YLXLdwImmcZUd6yzApCSARFZ6xOoYw_IuvvkBG_ug"
     }
}

thanx,
Anders R
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmobilepki.org%2fjcs&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4BxnKZzwfjHI9agf8KmyH9r8uq99%2bcJuynTGLfe7F5U%3d

_______________________________________________
jose mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SZEW0IWLt8eUw0nPilbQE45376rM41ChicZcQmLOeAE%3d

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Aug 2015 07:10:48 +0200

On 2015-08-10 06:33, Mike Jones wrote:
> You can represent unencoded header and payload values by using "b64":false
 > and "header" rather than "protected" with the JWS JSON Serialization.

Got that but "header" is not signed, right?

Anyway, the bigger picture is that "Predictable Serialization" is the de-facto
standard for HUMAN-authored JSON data including the JOSE RFCs and I-Ds.

By adding a mere 10-100 lines (required by _some_ JSON tools), you can finally
close the readability gap between HUMAN- and MACHINE-written JSON data.

If you do that you also get an entirely different set of possibilities for
human-readable, byte-efficient, and simple "in-object" JSON signatures like JCS.

For detached signatures (which IMO is another story) I think your I-D is quite useful!

Anders

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 9 Aug 2015 23:54:44 -0700

Anders,

If you truly have a "Predictable Serialization" that is general purpose
rather than only for a subset, please submit an ID with that information.
It would be highly valuable.  The JSON group is re-opening and it could
provide some good input for that.

I do not find that humans do predictable serializations when creating JSON
in any way.  They tend to either copy some example or put in fields as they
tend to remember them.  They don't, for example, sort them in an alphabetic
order by key name.

Jim

> Sent: Sunday, August 09, 2015 10:11 PM
> To: Mike Jones; [email-masked]
> Subject: Re: [jose] Payment Perspective on
draft-jones-jose-jws-signing-input-
> options 00
human-
> readable, byte-efficient, and simple "in-object" JSON signatures like JCS.
> 
> For detached signatures (which IMO is another story) I think your I-D is
quite
> useful!
> > Subject: [jose] Payment Perspective on
> > draft-jones-jose-jws-signing-input-options 00
> >
> > Hi JOSE WG,
> >
> > The JOSE standards grew out of OpenID and similar.  They obviously do a
great
> job in that space!
> >
> > So the question I have tried to answer is: How do the JOSE standards fit
in a
> more traditional XML or EDI context?
> >
> > SIZE:
> > If we start with size (which probably is the least important factor
here), JOSE
> signature schemes seem to have one thing in common: they need to
> Base64URL-encode protected header arguments which for X.509 certificates
> means two layers of Base64.  It doesn't take an Einstein to figure out
that
> signatures schemes that use header protection for explicit X.509 data
won't be
> particularly space-efficient.
> >
> > READABILITY:
> > This is a more complicated issue than one might think because JSON
> > unlike its "predecessors" does not depend on (or support)
> > position-based data which for example makes the modified sample in JWS
> > A.7
> >
> >        {
> >         "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-
> F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
> >         "payload":
> "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtc
> GxlLmNvbS9pc19yb290Ijp0cnVlfQ",
> > fully valid but slightly less pleasing to read.  Applied to JSON objects
with
> dozens of properties this (IMO) becomes a debug and document hurdle also
for
> systems that do not use signatures.
> >
> > Now going back to readability which was one of the motives behind draft-
> jones-jose-jws-signing-input-options 00...
> >
> > As far as I can tell, draft-jones-jose-jws-signing-input-options 00
doesn't really
> deal with signed JSON, it is rather a scheme for signing arbitrary UTF-8
data.  If
> you use this scheme for in-line signing of JSON data, readability would
suffer due
> to 1) typical JSON serializers' inability maintaining "insertion order" 2)
the code
> getting garbled by escape characters.
> >
> > If you would like to use a JSON schema for input validation things
become
> rather "hacky" since the signature and the data isn't in the same format.
> >
> > In some applications (like the ones I work with...), there's also a
disadvantage
> with embedding signatures since they change the structure of an object
> completely.   That signed PDFs is not about putting PDF data inside of a
CMS
> blob is not a coincidence!
> >
> > All those issues put together plus the fact that "predictable
serialization" is
> absolutely trivial to implement and has legitimate uses outside of
signatures
> makes me less convinced that the JOSE WG at this stage has a viable
solution for
> payments and such.
> >
> > However, that DOES NOT disqualify
draft-jones-jose-jws-signing-input-options
> 00 as a possible extension to existing JOSE standards.  The detached
version of
> the concept seems like a particularly useful thing!
> >
> > So, I'm still counting on a new scheme for payments. Although the
following
> JCS sample may look verbose, it is actually quite a bit more
byte-efficient than
> current JOSE signature schemes. Readability? Not even "pretty-printing"
breaks
> signatures.  Well, strings must of course not be folded...
> >
> > {
> >     "@context":
> "https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fxmlns.web
> pki.org%2fwebpay%2fv1&data=01%7c01%7cmichael.jones%40microsoft.com%
> 7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011d
> b47%7c1&sdata=zRirh4Ml%2bLrdObxfyIKPEiT%2fWTV8EkvxaWPwafW0ong%3d
> ",
> >         "softwareId":
> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=01%7c
> 01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b
> 64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXe
> U8QTmBGIvMxL%2fjTb1GKdtHSo%3d - Merchant",
> "MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNV
> BAYTAkRFM
> >
> SEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxM
> DAwMDAwWhc
> >
> NMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGOD
> k2MzI1MRYwFAYDV
> >
> QQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg
> KCAQEAgwj
> > GibfiCx8SOPyM-
> xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_Z
> > CeC018fC6cg9Yqc-
> vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141
> >
> ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXg
> N_42
> > kIJSANVwwKj6HhXZVnaHHQ4M-
> cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA
> > 0CRXYc-
> 3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wW
> > zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-
> DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTK
> >
> CIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvc
> NAQELB
> >
> QADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W
> 0xJxPo
> > 0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0-
> GTnVlXwC
> >
> kMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3J
> X-PIZoV7V
> > _q-wevUwAJfoeWF
> 21E
> >
> >
> Kgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu
> 866Nu
> > j9XmKorNmDAmrxN4tX64tzNIMnaoTXv6qifQal0hEVRlE7ONUNfY",
> >
> "MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJV
> UzEiMCAGA
> >
> 1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAw
> MDBaFw0yNTA
> >
> 3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudC
> BOZXR3b3JrI
> >
> FN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4Q
> Z5re1twR7
> > 9TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs-
> MVfiuDFmhTSfULT52o_mv5Re76n
> >
> 0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0
> uPUwjn
> > cRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK-
> vlHc5cvg1zd_G3HEECg
> > g-EYYXbwUppb-
> 7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcG
> >
> oe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8
> GA1UdEwEB_
> >
> wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue0
> 0dJGqQ79jesn
> > EIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi-
> a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCA
> >
> gEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxB
> FmHyVxZ
> >
> BRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbp
> KsTeolN
> > ceOVB8XzKz9Ti3TmmDt9VA20aruGw-
> Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N
> > 9m44Us8L6FZbRNa
> Pfk
> >
> VIfKRBGgtMziDUyyXrb0PisuRkdFenmkoqfO2d6QVho6SuNUlXd_pGNklKaQfEP-
> A6vN4XK7JpYhwgmhvrxKUUC9nfx601olcIcUm3TpewUz5t-
> s2Kpv4EVCAet6vKqHDH4A4oI2hOPEWSzhjqumtJmPguNGVdeBbdgZrVEl3XbwsRO
> qgYGGHLXURSRnySaIaUY-4Se8HgA-AHbn3MiK_pBz1Igj-
> mokjZILt51t6I77Qf_fTi9OJYBrAPkZozxUGN2RaQ6zPqPlIgrKQQwS_jTQg-
> z_QkctYP8V7w9__Z6Na8dCR9rBhoruBdKO1OPipT_qeqRVq3xzu-
> 80MFDRNouegE4UoS8_KTMwfisCKssrKydA7IIACMKa6V3BtGKD6ML3LhnhgfGQS
> oCxVU4v5QZ6866TImLRSl-E8M8SdeIZ4MKRV-oKPouq6B0d-0mrHkCstTilfI"
> >               ],
> >             "value": "AYUvS4Nq7cuHz8zCoXh_-
> vOWYKchnAAUfROaDbU1nGv9cM3H0uZz-
> W6d8v51jlBGq0bt9yWDpyjmd9FFqHSqLEf1FNTGTObAEpQ2ar6Lgvwmer-
> HXhi3Y5Hng7MqMokOZeF_tsbfZTffXg96BvFVRzUr3qBeCYPNMH7q2pTV_4L57sj4
> QssJkRfG-KxT1nSkhSGCD1big2Vfr_93CC0cKuURSJup2AwK-
> A3BJ3ax5QlW4YA2KBRiaSf6X1jlJhCFQZf-
> oaj7bUIna7kWd_f0ab869Co4H4HoDvECoDKa-JHqNw-
> NOeUAxT0brMHyKJ_Nvq8LUuiAzic3CPqIJaJSHA"
> >           }
> >       },
> >     "cardType": "SuperCard",
> >     "softwareId":
> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=01%7c
> 01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b
> 64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXe
> U8QTmBGIvMxL%2fjTb1GKdtHSo%3d - Bank",
> "MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1
> UEBhMCRVUxI
> >
> DAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTA
> wMDAwMFoXDTI
> >
> wMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDEx
> EzARBgNVBAMTC
> >
> m15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jB
> PfnNXhQo9Q
> > SGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A-
> y1DVC34oOF71EyPeAv74mxhjc3gElgo10wW
> > zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-
> DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUK
> >
> NflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0E
> AwIFA
> >
> ANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1
> QoIzr8
> > gH800AnBrdOtG9Xw9jI-Vb1ixyow0tA",
> >
> "MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJV
> UzEhMB8GA
> >
> 1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAw
> MFoXDTI1MDc
> >
> xMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgT
> mV0d29yayBTd
> >
> WIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391
> eOhqzmBr
> >
> aQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNj
> MGEwDwYDV
> >
> R0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJ
> pVvUo_C4Vye
> >
> TArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCS
> qGSIb3DQEBD
> > QUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC-
> XfSed9PJYuR2slXij3w2DFmxYHmbSVH4d
> > ZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F-
> qLVUpdFwEww1POd8T0n02Y
> > ouRDSi4HWUY003C9hB6ouTdfHaswR6-
> cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd3
> > 2gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI-
> GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l
> >
> _ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQ
> jNDig
> >
> ESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqis
> myMWN
> >
> gIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75Utg
> Tx1-Jf
> > p6B3Qyji8pDR_Ba
> 3eU
> >
> lz1BJhyFuC8cHL275S8zQ2jCyjnaMXZvm_EnZGpOcm4DZrPD3cujBc1E09LyujylglLi
> N_up0I_ImliqF0GIA1o-s3nk7F1QlTe-7HWsbTrPOocm3SHDmyJEOgz8ChftelxeQ5-
> 2hhz5QURdmmUIPUrDBcK1I5Fopv2-SPmNipPkZ1o7Gz1Mbqzrg"
> >           ],
> >         "value":
> "bUZ2bjXVKQisr_RyYG1Ru0P263ft1LkmhLnBTg94AjYQ4YLXLdwImmcZUd6yzApC
> SARFZ6xOoYw_IuvvkBG_ug"
> >       }
> > }
> >
> > thanx,
> > Anders R
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmobil
> >
> epki.org%2fjcs&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb
> 06
> >
> 08b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd
> ata=
> > 4BxnKZzwfjHI9agf8KmyH9r8uq99%2bcJuynTGLfe7F5U%3d
> >
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> >
> etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40mic
> >
> rosoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91
> ab2d
> >
> 7cd011db47%7c1&sdata=SZEW0IWLt8eUw0nPilbQE45376rM41ChicZcQmLOeAE
> %3d
> >
> 
> https://www.ietf.org/mailman/listinfo/jose

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Aug 2015 10:10:56 +0200

> provide some good input for that.

My take on "Predictable Serialization" is extremely simple both from a definition-
and implementation-point of view ; it only means that the order and contents of
properties is respected during parsing and serialization.  This doesn't violate
RFC 7159 but isn't supported by it either.

An I-D would mainly be a rationale.

> tend to remember them.  They don't, for example, sort them in an alphabetic

Right.  What I meant is that when humans are authoring JSON data they tend to
put properties in a for the context logical order.

Anders
http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html

---

From: Mike Jones <[email-masked]>
Date: Mon, 10 Aug 2015 15:47:30 +0000

Hi Anders,

You're right that "header" header is not signed.  If you want to integrity-protect the headers, you'd use "protected", which base64url encodes the headers so that a canonical JSON representation doesn't have to be defined or used.  I suspect that it's really the payload that you're interested in being human-readable - whereas the headers are likely to contain relatively uninteresting content - usually an "alg" and a "kid", and so making them human-readable is not as big a deal as whether the payload is.  But that's a judgement call that each deployer gets to make.

As you know, the JOSE working group intentionally stayed away from defining or using a canonical JSON encoding and instead opted for base64url encoding when it was necessary to represent arbitrary byte sequences, including arbitrary JSON representations.  You're free to define different specs that make different choices, but that's up to you and whatever working group you might charter and its members.

Thanks again for your review and for expressing the opinion that the I-D is quite useful for detached signatures.

				Best wishes,
				-- Mike

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Sunday, August 09, 2015 10:11 PM
To: Mike Jones; [email-masked]
Subject: Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

Anyway, the bigger picture is that "Predictable Serialization" is the de-facto standard for HUMAN-authored JSON data including the JOSE RFCs and I-Ds.

By adding a mere 10-100 lines (required by _some_ JSON tools), you can finally close the readability gap between HUMAN- and MACHINE-written JSON data.

If you do that you also get an entirely different set of possibilities for human-readable, byte-efficient, and simple "in-object" JSON signatures like JCS.

Anders

> "MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNVBAYTAkRFM
> SEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxMDAwMDAwWhc
> NMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGODk2MzI1MRYwFAYDV
> QQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgwj
> GibfiCx8SOPyM-xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_Z
> CeC018fC6cg9Yqc-vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141
> ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXgN_42
> kIJSANVwwKj6HhXZVnaHHQ4M-cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA
> 0CRXYc-3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wW
> zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTK
> CIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvcNAQELB
> QADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W0xJxPo
> 0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0-GTnVlXwC
> kMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3JX-PIZoV7V
> _q-wevUwAJfoeWF
21E
>   
> Kgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu866Nu
> "MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJVUzEiMCAGA
> 1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAwMDBaFw0yNTA
> 3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrI
> FN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4QZ5re1twR7
> 9TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs-MVfiuDFmhTSfULT52o_mv5Re76n
> 0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0uPUwjn
> cRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK-vlHc5cvg1zd_G3HEECg
> g-EYYXbwUppb-7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcG
> oe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8GA1UdEwEB_
> wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue00dJGqQ79jesn
> EIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi-a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCA
> gEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxBFmHyVxZ
> BRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbpKsTeolN
> ceOVB8XzKz9Ti3TmmDt9VA20aruGw-Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N
> 9m44Us8L6FZbRNa
Pfk
> "MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1UEBhMCRVUxI
> DAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTAwMDAwMFoXDTI
> wMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDExEzARBgNVBAMTC
> m15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jBPfnNXhQo9Q
> SGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A-y1DVC34oOF71EyPeAv74mxhjc3gElgo10wW
> zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUK
> NflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0EAwIFA
> ANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1QoIzr8
> "MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJVUzEhMB8GA
> 1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAwMFoXDTI1MDc
> xMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTd
> WIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391eOhqzmBr
> aQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNjMGEwDwYDV
> R0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJpVvUo_C4Vye
> TArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCSqGSIb3DQEBD
> QUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC-XfSed9PJYuR2slXij3w2DFmxYHmbSVH4d
> ZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F-qLVUpdFwEww1POd8T0n02Y
> ouRDSi4HWUY003C9hB6ouTdfHaswR6-cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd3
> 2gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI-GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l
> _ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQjNDig
> ESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqismyMWN
> gIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75UtgTx1-Jf
> p6B3Qyji8pDR_Ba
3eU
> epki.org%2fjcs&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb06
> 08b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=
> rosoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d
> 7cd011db47%7c1&sdata=SZEW0IWLt8eUw0nPilbQE45376rM41ChicZcQmLOeAE%3d
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 12:27:13 -0700

There are many things about JWS which I dislike. However, the fact that it
will allow for stupid intermediates to grab and potentially change things in
ways which JSON permits is one of the things that is goodness.

I am afraid that I still believe that you do not have a workable solution to
the problem at this time.  There are far too many ways that order may not be
respected and of course you don't deal with numbers.

jim

> Sent: Monday, August 10, 2015 1:11 AM
> To: Jim Schaad; 'Mike Jones'; [email-masked]
> > If you truly have a "Predictable Serialization" that is general
> > purpose rather than only for a subset, please submit an ID with that
> information.
> > It would be highly valuable.  The JSON group is re-opening and it
> > could provide some good input for that.
> 
> My take on "Predictable Serialization" is extremely simple both from a
> definition- and implementation-point of view ; it only means that the
order and
> contents of properties is respected during parsing and serialization.
This doesn't
> violate RFC 7159 but isn't supported by it either.
> 
> > I do not find that humans do predictable serializations when creating
> > JSON in any way.  They tend to either copy some example or put in
> > fields as they tend to remember them.  They don't, for example, sort
> > them in an alphabetic order by key name.
> 
> >> By adding a mere 10-100 lines (required by _some_ JSON tools), you
> >> can
> > finally
> >> Base64URL-encode protected header arguments which for X.509
> >> certificates means two layers of Base64.  It doesn't take an Einstein
> >> to figure out
> > that
> >>> That protected headers are Base64URL-encoded is also a readability
> >>> (and
> >> debug) impediment.
> >>>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Aug 2015 22:52:48 +0200

> ways which JSON permits is one of the things that is goodness.

Sure.  No disagreement on that.

> respected and of course you don't deal with numbers.

It seems that you require a solution to work with broken software as well?

My reference implementations in Java, JavaScript, and Python deal with numbers
in the same way as with all property data which is keeping the textual
information "as is".  That is, a parsed property like

    "volume":1.50

would during serialization come out as

    "volume":1.50

This server may not always be up-and-running but you should after a few
minutes of playing be able to verify my claims: https://mobilepki.org/jcs

The problem as I see it is rather that the financial sector doesn't have a
suitable signature standard for JSON data.

Anders

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Aug 2015 14:00:35 -0700

> Sent: Monday, August 10, 2015 1:53 PM
> To: Jim Schaad; [email-masked]
> > There are many things about JWS which I dislike. However, the fact
> > that it will allow for stupid intermediates to grab and potentially
> > change things in ways which JSON permits is one of the things that is
> goodness.
> 
> > I am afraid that I still believe that you do not have a workable
> > solution to the problem at this time.  There are far too many ways
> > that order may not be respected and of course you don't deal with
numbers.
> It seems that you require a solution to work with broken software as well?

How is the software broken.  It meets the JSON standard and is sitting
between me and the target system doing some type of snooping to verify that
only data that should be is being transmitted.  It may write things back out
and not preserve the order which is completely legal JSON.

> 
> My reference implementations in Java, JavaScript, and Python deal with
> numbers in the same way as with all property data which is keeping the
textual
> would during serialization come out as

Ah yes - we are going to make numbers into strings not numbers.  I am not
sure that this works for anybody sitting in the middle that does not know
they are supposed to be doing this.  

Again - you have a special case solution not a general solution that will
work with any JSON parser that I happen to write.  I may have good reasons
to use a hash table to keep the map in (makes it easier to do comparisons
against known bad patterns for example).  Any system that assumes that a
JSON structure is going to be serialized out in the same order all of the
time is not broken, but will cause you to exhibit failures.

I am just not interested in this I guess.

Jim

> The problem as I see it is rather that the financial sector doesn't have a
suitable
> signature standard for JSON data.
> 
> Anders
> 
> >
> > jim
> >
> >>> I do not find that humans do predictable serializations when
> >>> creating JSON in any way.  They tend to either copy some example or
> >>> put in fields as they tend to remember them.  They don't, for
> >>> example, sort them in an alphabetic order by key name.
> >>
> >> Right.  What I meant is that when humans are authoring JSON data they
> >> tend
> > to
> >>>> Anyway, the bigger picture is that "Predictable Serialization" is
> >>>> the
> >>> de-facto
> >>>> readable, byte-efficient, and simple "in-object" JSON signatures
> >>>> like
> > JCS.
> >>>>
> >>>> certificates means two layers of Base64.  It doesn't take an
> >>>> Einstein to figure out
> >>> that
> >>>> completely.   That signed PDFs is not about putting PDF data inside
of
> > a
> >>>> "https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fxm
> >>>> ln
> >>>> s.web
> >>>>
> >>
> >>>> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data
> >>>> =0
> >>>> 1%7c
> >>>>
> >>
> >>>> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data
> >>>> =0
> >>>> 1%7c
> >>>>
> >>
> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fm
> >>>>> ob
> >>>>> il
> >>>>>
> >>>>
> >>
> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
> >>>>> ww
> >>>>> .i
> >>>>>
> >>>>
> >>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 11 Aug 2015 07:07:18 +0200

> I am just not interested in this I guess.

Yes, the JOSE WG have more or less unanimously decided to ignore the
needs of the financial community who wants to sign JSON objects [1]
rather than signing arbitrary data using JSON-based signature containers.

Anders

1] Although entirely different with respect to JSON normalization, the following
independently developed schemes proposals seem to support this statement:

https://web-payments.org/specs/source/vocabs/security.html#GraphSignature2012
https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Sample_Signature

---

From: Mike Jones <[email-masked]>
Date: Tue, 11 Aug 2015 05:41:28 +0000

I would think that the financial community would want a reliable signature method, without the interop problems that relying on canonicalization creates, as so thoroughly demonstrated in practice by XML Canonicalization.  For starters, there isn't actually a JSON canonicalization standard in the first place.  And relying on intermediaries not modifying the JSON in any way is also fraught with danger and an invitation to attacks.

Would using JWS with detached payloads really be that onerous for this community, provided they actually have a way to preserve the payload exactly?

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Monday, August 10, 2015 10:07 PM
To: Jim Schaad; [email-masked]
Subject: Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

> I am just not interested in this I guess.

Yes, the JOSE WG have more or less unanimously decided to ignore the needs of the financial community who wants to sign JSON objects [1] rather than signing arbitrary data using JSON-based signature containers.

Anders

1] Although entirely different with respect to JSON normalization, the following independently developed schemes proposals seem to support this statement:

---

From: "Nat Sakimura" <[email-masked]>
Date: Tue, 11 Aug 2015 14:42:20 +0900

Anders, 

You are not alone. I, although one of the author of JWS, am very sympathetic
to the needs of the financial community. My work originally started from the
needs to sign a JSONized financial transaction data. Having said that, ASCII
armoring came pretty early in the course, much before JOSE WG was
established because of the difficulty of 
    a) generally assuming intermediate will not alter the content; and 
    b) generalized canonicalization of JSON.  
We opted to accept the model that the output of JWS is to be consumed by
human being through an application and not as a text instead of dealing with
the problems above. 

I still think b) is hard, but in a closed environment, a) is not that hard. 
That is where jws-signing-input-options would be useful, IMHO. 

-- 
Nat Sakimura <[email-masked]>
Nomura Research Institute, Ltd. 

PLEASE READ:
The information contained in this e-mail is confidential and intended for
the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified
that any review, dissemination, distribution or duplication of this message
is strictly prohibited. If you have received this message in error, please
notify the sender immediately and delete your copy from your system.

> Sent: Tuesday, August 11, 2015 2:07 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Yes, the JOSE WG have more or less unanimously decided to ignore the needs
of
> the financial community who wants to sign JSON objects [1] rather than
signing
> arbitrary data using JSON-based signature containers.
> 
> Anders
> 
https://web-payments.org/specs/source/vocabs/security.html#GraphSignature20
> 12
https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Sample_Si
> gnature

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 11 Aug 2015 08:52:24 +0200

On 2015-08-11 07:41, Mike Jones wrote:
> I would think that the financial community would want a reliable signature method,

Indeed.

> without the interop problems that relying on canonicalization creates, as so
 > thoroughly demonstrated in practice by XML Canonicalization.

Absolutely!

> For starters, there isn't actually a JSON canonicalization standard in the first place.

True.  As I have shown in specifications, code, etc. there's no need for such a thing either.

> And relying on intermediaries not modifying the JSON in any way is also fraught with
 > danger and an invitation to attacks.

It is possible that my analysis is flawed, but as far as I can tell, the only thing
an adversary (or poorly working intermediary), could succeed with by a substitution
attack on JCS [1], is invalidating signatures which I (FWIW) wouldn't characterize
as a security problem but as a nuisance and interoperability issue.

> Would using JWS with detached payloads really be that onerous for this community,
 > provided they actually have a way to preserve the payload exactly?

If nothing else helps they would go for that but as shown there are (at least)
a couple of efforts out there pointing to more "JSONesque" schemes.

My guess is that there are many other JSON signature schemes in the workings we
don't know of, since financial communities tend to be rather tight-lipped :-)

It is important to realize that I'm in _no way_ "dissing" the JOSE work, I only
see it as less suitable for the target market I mentioned.

Best regards,
Anders

1] https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#Sample_Signature

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 11 Aug 2015 10:57:21 +0100

Hi Anders
Not sure if it makes sense, but can the ordering requirement be relaxed 
and instead JSON keys are sorted first (natural string sorting) before 
the signature is created or validated ? Though it is probably not 
effective as it can block streaming...

Cheers, Sergey
On 11/08/15 07:52, Anders Rundgren wrote:
> 1]
>> 1] Although entirely different with respect to JSON normalization, the
>> following independently developed schemes proposals seem to support
>> this statement:
>>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 11 Aug 2015 12:18:00 +0200

> effective as it can block streaming...

Hi Sergey,

The point I have tried to make (and failed with) is that "Predictable Serialization"
is a generic usable JSON feature.

http://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html

   "This technique is particularly useful if a module takes a map on input,
    copies it, and later returns results whose order is determined by that
    of the copy. (Clients generally appreciate having things returned in the
    same order they were presented.)"

Clients = Users.

Sorting would defeat the readability requirement and also depend on external
signature processing code.  In my take on this topic, the parser/serializer
does all signature processing except for the core cryptographic operations.

Anders

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 12 Aug 2015 11:20:42 +0100

Hi Anders

I'm interesting in experimenting with JCS in our project, possibly 
implemented, I've created an issue to keep it on the map. It does not 
have to be RFC :-)...
Now that I think about it I'm not even sure I understand why the 
ordering constraint is a problem, even the most primitive reader/writer 
I did myself uses LinkedHashMap.

The situation where an intermediary uses some 3rd party parser that 
reads a payload then add something new and produces a different order 
appears to be somewhat isolated (in fact I'm not sure it is practically 
realistic because this intermediary would also need to have the same 
same signing/validating key and the problem of distributing the key 
securely between many parties in the chain appears to be much more 
complex for the actual exercise even to tale place). Sorry all if I 
misunderstood something :-)

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 12 Aug 2015 11:22:50 +0100

And sorry all for so many typos. I blame a new keyboard :-)
On 12/08/15 11:20, Sergey Beryozkin wrote:
>>>> True.  As I have shown in specifications, code, etc. there's no need
>>>> for
>>>> such a thing either.
>>>>
>>>>
>>>> It is possible that my analysis is flawed, but as far as I can tell,
>>>> the
>>>> only thing
>>>> It is important to realize that I'm in _no way_ "dissing" the JOSE
>>>> work,
>>>> I only

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 12 Aug 2015 14:34:55 +0200

> misunderstood something :-)

Totally agree (of course) :-)

JCS (and GraphSignature) were designed to add a "Signed" capability to existing
JSON objects while keeping the message structure intact since business folks
tend to care more about their messages than about signatures.

This may sound a bit sloppy but assuming that both interests actually can be met, why not? :-)

I'm considering an RFC in the same vein as JSON-I where "Predictive Serialization"
would be outlined since this is really the core idea and a possible quality factor
for future JSON tools.

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 25 Aug 2015 17:21:01 +0200

I just want to end this thread by stating a requirement which is outside of current
JOSE specifications [1] and that is the anticipated use of "Babushka" signatures
(signed messages enclosing other signed messages).

As an example, a recent version of a system for challenging the 20-year standstill on secure
credit-card payments on the Web [2], needs not less than 3 levels of signed JSON messages,
each including protected headers in excess of a kilobyte (X.509 certificates).

I can't imagine that the <100 lines of code required to make the .NET "JavaScriptSerializer"
fully compliant with "Predictable Serialization" would actually be a show-stopper.

Detached signatures is an entirely different animal which new draft addresses quite well.

Cheers,
Anders

1] Strictly technically JWS can do what I outline but the result would simply look
too bad for human consumption while computers obviously don't care.

2] Here disregarding VISA's 3D Secure which has been largely rejected since it is
neither secure or convenient as well as schemes based on super-providers like PayPal.