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

Anders Rundgren anders.rundgren.net at gmail.com
Mon Nov 13 09:53:02 UTC 2017

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.


> 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> 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=
>>    "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=) 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=
>> 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
>> 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=

More information about the Openid-specs-fapi mailing list