Re: M2M DID Auth

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?

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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&amp;sdata=nkyafdlOaYogY5KngqKeglKcXio%2BfBOyEOXP%2BsfGXGo%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&amp;sdata=q7QHCpdWv%2B0fXfkvDAinnH7xNHyyY9pjXRXpZp2qTrA%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&amp;sdata=1J8j%2Fp%2FhyEXokDC37a3CjP%2FYCjSnw7XamVXT2GXO2ps%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&amp;sdata=oOzM%2F%2BEAGgo6UpmgTIS2m3yRztNdV0AeGWbOm3sU4H0%3D&amp;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&amp;data=02%7C01%7Clrosenth%40adobe.com%7C6245d50f720047a80db208d802b494e3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637262321898877133&amp;sdata=7m%2FtdwdcljJApz1Z0%2FiEjUTfVcxIPowyDbpE5oNIPbs%3D&amp;reserved=0

Received on Thursday, 28 May 2020 13:20:33 UTC