[Openid-specs-fapi] Berling group consultation response table

Anders Rundgren anders.rundgren.net at gmail.com
Tue Nov 14 16:41:48 UTC 2017


On 2017-11-14 15:32, Dave Tonge wrote:
 > Hi Anders,

Hi Dave,

 > OpenBanking decided to use detached JWS for this use-case:
 >
 > https://tools.ietf.org/html/rfc7515#appendix-F and https://tools.ietf.org/html/rfc7797
 >
 > This requires both the resource server and the client to agree on
 > the method by which the "payload" is encoded and therefore by which
 > its signature can be verified. However, it is standards compliant,
 > and for "new" APIs seems to have advantages.

Right.  What's somewhat less great is that this scheme doesn't really sign REST requests since these are defined by Payload + URI + HTTP verb + And maybe other HTTP headers as well.

Since I (in my work as an individual inventor NB...), do not have to settle for such compromises, I took the liberty of slaughtering not just one sacred cow (REST is mandatory for contemporary Internet standards), but two, by not building on IMHO rather "artificial" [*] detached data constructs. Signatures in my scheme nowadays rely on a fairly recent version of JavaScript (ES6) supporting "predictive" parsing/serialization as a standard feature and is compatible with current versions of Chrome, Firefox, and Safari as well as with Node.js.

Although I don't expect this group to adopt any of this it may anyway be worth a quick read: https://cyberphone.github.io/doc/web/yasmin.html

With the help of a minute library of mine the signature scheme works flawlessly on server- and Android-java as well. JCS = JWA + JWK + ES6.JSON + AR

Cheers,
Anders (AR)

*] The quite reasonable desire keeping signed JSON data human-readable has lead to loads of "DIY standards" of various caliber, including in the W3C.

 >
 > Other options considered were that the resource server to return JWTs instead of JSON, i.e. it returns the conent-type "application/jwt"
 > This is also standards compliant, but it was felt that the tooling is not mature enough for this option to be developer friendly.
 >
 > Dave
 >
 > On 13 November 2017 at 09:53, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
 >
 >     On 2017-11-13 10:25, Phil Hunt (IDM) wrote:
 >
 >         Fwiw. We looked at signed http requests as part of proof of possession specs.
 >
 >
 >         The advice from key members of the http wg is that http request signing is impossible. Too much water under the bridge with isps, gateways, balancers and proxys messing with messages.
 >
 >
 >     Indeed.  Unfortunately it also means that "proper" signing of REST requests is impossible/not recommended.
 >
 >     Combining that with the desire of also using Browsers/JS as well as WebSockets for carrying "business messages", my conclusion was that the REST concept squarely matches the needs of *my* kind of work.
 >
 >     Anders
 >
 >
 >         So yes you can do it in a lab environment. But having a 10% (or whatever the number is) false fail rate in production is not usable in the real world.
 >
 >         To sign requests you have to have a content type that does this. I seem to recall ws-* hd request signing but still suffering scars.
 >
 >         Phil
 >
 >             On Nov 13, 2017, at 5:09 PM, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
 >
 >                 On 2017-11-12 20:49, Nat Sakimura via Openid-specs-fapi wrote:
 >                 Dear FAPIers:
 >                 I have started to paste the comments that I got by now into the
 >                 following google doc.
 >
 >
 >             Hi Nat,
 >             May I take the liberty commenting a bit on this?
 >
 >                 https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1fh09jiJGITuefXkB1Zq3oCrhHNvP5BWXDrpKPJK-5FiRE_edit-3Fusp-3Dsharing&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=-_n_hjGDPSb-65_v6NuK9xZgsc-2ZN6VPWaue57_AW8&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1fh09jiJGITuefXkB1Zq3oCrhHNvP5BWXDrpKPJK-5FiRE_edit-3Fusp-3Dsharing&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=-_n_hjGDPSb-65_v6NuK9xZgsc-2ZN6VPWaue57_AW8&e=>
 >
 >
 >                 "4.2 [signHTTP] is not  a standard nor it is on the way to become standard.
 >                  It has not and is not going under the rigor of the standardization process"
 >
 >             FWIW, the STET PSD2 API (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.stet.eu_en_news_news1_stet-2Dpsd2-2Dapi-2Dis-2Dnow-2Davailable.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=pyTgj5xuZ0AD3s770l7oKscOELvtX68LJtkcAhpLV90&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.stet.eu_en_news_news1_stet-2Dpsd2-2Dapi-2Dis-2Dnow-2Davailable.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=pyTgj5xuZ0AD3s770l7oKscOELvtX68LJtkcAhpLV90&e=>) also builds on [signHTTP].
 >
 >             AFAICT there is little else you can do if you want to be fully faithful to the REST philosophy since a request is qualified by Payload + Headers + Verb.
 >
 >             Due to the problems combining signatures and REST requests ("non-standard" as you say), as well as to REST's limited usability for interactive (bi-directional) Wallet communication, I "invented" a scheme called YASMIN:
 >             https://urldefense.proofpoint.com/v2/url?u=https-3A__cyberphone.github.io_doc_web_yasmin.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=5riJjr107NACSCT-xVxjYuL0VTUWIOMoPiOXmJuCtjo&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__cyberphone.github.io_doc_web_yasmin.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=5riJjr107NACSCT-xVxjYuL0VTUWIOMoPiOXmJuCtjo&e=>
 >
 >             Anders
 >
 >                 I have not incorporated the OBIE response ideas yet. If you guys are
 >                 interested, please let me know so that I can send their comments
 >                 privately.
 >
 >
 >             _______________________________________________
 >             Openid-specs-fapi mailing list
 >             Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
 >             https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfapi&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=RsGWklKg4SMG8_KQR0ahMcV9gnDd-zQEMNDW-RArMhw&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dfapi&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ8&s=RsGWklKg4SMG8_KQR0ahMcV9gnDd-zQEMNDW-RArMhw&e=>
 >
 >
 >
 >     _______________________________________________
 >     Openid-specs-fapi mailing list
 >     Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
 >     http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
 >
 >


More information about the Openid-specs-fapi mailing list