- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Thu, 28 May 2020 17:21:29 +0200
- To: Leonard Rosenthol <lrosenth@adobe.com>, Justin Richer <jricher@mit.edu>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, "public-credentials@w3.org" <public-credentials@w3.org>, Annabelle Richard Backman <richanna@amazon.com>
On 2020-05-28 15:20, Leonard Rosenthol wrote: > Anders - good to hear from you and quite interesting work...I remember when you started it and good to see it continue. > > My biggest concern with JCS as you have it defined is that it appears (from my quick read) that it won't work on JSON-LD but only on the strict I-JSON requirements. Is that a fair statement? H Leonard, Thanx! JCS is now on its seventh year although it surely ended-up as an entirely different solution than the one I started with... I'm actually happy that my original idea was slammed by the IETF folks :) JCS works with anything that is compatible with I-JSON. If you in an JSON-LD context use data that is outside of I-JSON it probably means that your system doesn't interoperate with JavaScript which IMO is kind of a showstopper. Thanx, Anders > > Leonard > > On 5/27/20, 11:09 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com> wrote: > > On 2020-05-27 22:37, Leonard Rosenthol wrote: > > Thanks for the detailed response, Justin! I will take this back with me to ETSI and make sure that we align… > > > > I’ll do my best to participate where and when I can…appreciate the links. > > > > Leonard > > For completeness: > > A method for canonicalizing JSON (or to be more correct the I-JSON subset), is currently in the RFC editor's queue in the form of an Independent Stream submission: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-rundgren-json-canonicalization-scheme-17&data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&sdata=nkyafdlOaYogY5KngqKeglKcXio%2BfBOyEOXP%2BsfGXGo%3D&reserved=0 > > JCS enables "Clear text signed JSON" in the same manner as XMLDsig did but at 5% of the complexity. > The Nodejs version has been downloaded millions of times so apparently there is some interest in this as well. > > JCS can easily be combined with JWS which you can test in an on-line service: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmobilepki.org%2Fjws-jcs%2Fhome&data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&sdata=q7QHCpdWv%2B0fXfkvDAinnH7xNHyyY9pjXRXpZp2qTrA%3D&reserved=0 > > Personally, I have taken this one step further since Base64Url encoding of header data is entirely redundant if you have canonicalization: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyberphone.github.io%2Fdoc%2Fsecurity%2Fjsf.html&data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&sdata=1J8j%2Fp%2FhyEXokDC37a3CjP%2FYCjSnw7XamVXT2GXO2ps%3D&reserved=0 > > How does this relate to "Signed HTTP" you may rightfully wonder. Well, the pragmatic approach I have taken in Saturn has proved to be quite useful. That is, don't use HTTP headers for conveying data that needs to be signed with the URL as the sole exception. > > Then you end-up with messages like: > { > "recipientUrl": "https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Ftransact&data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&sdata=oOzM%2F%2BEAGgo6UpmgTIS2m3yRztNdV0AeGWbOm3sU4H0%3D&reserved=0", > "timeStamp": "2020-05-20T10:00:00Z", > > ...other JSON data > > "signature": { > "algorithm": "ES256",? > "publicKey": {? > "kty": "EC",? > "crv": "P-256", > "x": "censDzcMEkgiePz6DXB7cDuwFemshAFR90UNVQFCg8Q", > "y": "xq8rze6ewG0-eVcSF72J77gKiD0IHnzpwHaU7t6nVeY"? > }, > "value": "EaGSWKQK6DFHVe8RJHlhA5c3qKSN1Gjh....Pdi6vaxdA8ofiAW6Py-wxWUNFxybSTAA" > } > } > > Unlike the "detached" solutions that are currently on the table, this method enables serialization, embedding, and counter-signing of HTTP requests. > > Sincerely, > Anders Rundgren > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyberphone.github.io%2Fopenbankingwallet%2F&data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&sdata=7m%2FtdwdcljJApz1Z0%2FiEjUTfVcxIPowyDbpE5oNIPbs%3D&reserved=0 > > > >
Received on Thursday, 28 May 2020 15:21:46 UTC