[jose] Sidemeeting Re: Signed HTTP Requests @ IETF-104

[Anders Rundgren <[e-mail]>]

On 2019-03-26 08:12, Bret Jordan wrote:
> I would love to have a side meeting here in Prague.

Bret and Torsten,
any suggestions for a suitable time?

Anders

> 
> I can not stress enough how important this JCS work is.  Anders talks about the banking industry using this.  But In addition to the banking sector, the entire international cyber threat intelligence community will be using JCS, which includes hundreds of major and small vendors, nearly every industry vertical, and many governments around the globe.
> 
> Like so many things, we should quit trying to censor technology because a few people do not like it, or because we wish the industry would go in a different path.  Anders has done amazing and brilliant work here.  Is it going to cover ever corner case? Probably not.  But honestly it does not need to.  It just needs to solve the problems people need, and it does.
> 
> How can we get this group to reconsider it?
> 
> 
> Bret
> 
> Sent from my Commodore 128D
> 
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> 
> On Mar 26, 2019, at 7:16 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On 2019-03-25 15:31, Torsten Lodderstedt wrote:
>>> Will there be a side meeting on Wednesday?
>>
>> I can try to arrange that.
>>
>> I'm still curious to hear what for example FAPI suggest for the future. https://openid.net/specs/openid-financial-api-part-2.html#request ?
>> Convincing all open banking system developers out there to dress their precious business messages in base64 as an alternative to their current clear text solutions including the-not-as-bad-as-claimed https://tools.ietf.org/html/draft-cavage-http-signatures-10 may turn out bad.
>>
>> JSON canonicalization as described in the current 05 draft is based on a concluded (and technically pretty successful) research effort verified by multiple implementations including one made externally [1].  There is a single fully documented issue [2] which do requires some considerations by clients to work.
>>
>> Number serialization have been addressed by true specialists in this field (=not me).  Recently I verified my original algorithm (copied from V8) with 5 billion random values against a new algorithm developed by Google which Microsoft intends to use in a coming updates to their C# tool chain.
>>
>> No such information was available during the operational time of the JOSE WG which is a rather important thing to keep in mind.
>>
>> A bunch of people at the IETF meeting privately propose that new developments should drop JSON/JWS and rather go for CBOR/COSE.  That's actually quite logical since with Base64-encoded messages, you anyway need a decoder to make messages human readable. Personally I'm doing the opposite namely applying canonicalization to the JWS itself [3]
>>
>> Anders
>>
>> 1] https://github.com/dryruby/json-canonicalization
>>
>> 2] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-05#appendix-E
>>
>> 3] User payment authorization in "Saturn".  Similar to XML DSig but at 10% of the complexity:
>> {
>>  "requestHash": {
>>    "alg": "S256",
>>    "val": "cA-QNdJHcynjuM44ty-zXgXwx100AZVRFLmYx1So0Xc"
>>  },
>>  "domainName": "demomerchant.com <http://demomerchant.com>",
>>  "paymentMethod": "https://bankdirect.net",
>>  "accountId": "8645-7800239403",
>>  "timeStamp": "2019-03-23T10:33:02+01:00",
>>  "signature": {
>>    "alg": "ES256",
>>    "jwk": {
>>      "kty": "EC",
>>      "crv": "P-256",
>>      "x": "rQ4WXMB6_wQKHSiY_mbJ4QkGpfWLssF7hvIiiFpDEx8",
>>      "y": "Fh2rl0LGTtvaomOuhuRNo9Drz9o0--WXV2ITvdVQFRY"
>>    },
>>    "val": "j2LL9pr2RyrPxvFlj8IzMhno5vvgGIgf2xi23dA5u_XwjYlIvT9qwIVKaCKYwjb26J5mMUL5zV02lqQGjZRClw"
>>  }
>> }
>>
>>
>>> Am 13.03.2019 um 06:36 schrieb Bret Jordan <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>>:
>>>> We should for sure setup a side meeting on Wednesday to talk about JCS.  That would be good.  We could also talk a bit after the HotRFC session.
>>>>
>>>>
>>>> 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 Mar 12, 2019, at 11:03 PM, Anders Rundgren <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> On 2019-03-13 04:46, Anthony Nadalin wrote:
>>>>>> I'm not sure why you say that FAPI is rolling it's own as we are not, please explain
>>>>>
>>>>> I was referring to this part of FAPI/OpenID:
>>>>> https://openid.net/specs/openid-financial-api-part-2.html#introduction-3
>>>>>
>>>>> Is that a proposed standard?  It claims to be RESTFul but does not deal with HTTP Method and URI which are fundamental parts of REST.
>>>>>
>>>>> In addition, one of the major interested parties behind FAPI, Open Banking in the UK, have selected another method (https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00#appendix-B.3), while other players in this field including French banks and the Berlin group are betting on: https://tools.ietf.org/html/draft-cavage-http-signatures-10
>>>>>
>>>>> This is the motivation behind this work.  If you are in Prague, maybe we can talk about this?
>>>>>
>>>>> regards,
>>>>> Anders
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: jose <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> On Behalf Of Anders Rundgren
>>>>>> Sent: Monday, March 11, 2019 8:57 AM
>>>>>> To: [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>> Subject: [jose] Signed HTTP Requests @ IETF-104
>>>>>> I will be there Saturday evening - Thursday 13.00 in case you are interested in this topic.
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-rundgren-signed-http-requests-00&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=gXhXwQOm0vwPvXbQUQj%2FwD3%2FrsDU%2BB95SF6CjfR80CA%3D&amp;reserved=0
>>>>>> 4 minute "lightning" talk: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyberphone.github.io%2Fietf-signed-http-requests%2Fhotrfc-shreq.pdf&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=Al4bQN9BkM8ESKwqIZD6q1ZeQhYc5PrlXDR7vuRy6JQ%3D&amp;reserved=0
>>>>>> On-line "laboratory":
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmobilepki.org%2Fshreq%2Fhome&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=bLjKK%2FcGsB54%2B%2FVbbQQDrrgxdCooQp0%2BfJDBBsRIg8M%3D&amp;reserved=0
>>>>>> thanx,
>>>>>> Anders
>>>>>> _______________________________________________
>>>>>> jose mailing list
>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjose&amp;data=02%7C01%7Ctonynad%40microsoft.com%7Ccdd16fdc2e264a6868ac08d6a63a4098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636879166457446453&amp;sdata=Ah7rSZOWkkeTs%2Byi76vkqK1O5iN%2FckkCRoGvtsUDWYc%3D&amp;reserved=0
>>>>>
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/jose
>>