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

Dave Tonge dave.tonge at momentumft.co.uk
Tue Nov 14 14:32:31 UTC 2017

Hi Anders,

OpenBanking decided to use detached JWS for this use-case:

https://tools.ietf.org/html/rfc7515#appendix-F and

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.

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.


On 13 November 2017 at 09:53, Anders Rundgren via Openid-specs-fapi <
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> 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.go
>>>> ogle.com_document_d_1fh09jiJGITuefXkB1Zq3oCrhHNvP5BWXDrpKPJK
>>>> -5FiRE_edit-3Fusp-3Dsharing&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8P
>>>> Zh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL
>>>> cLN4KZNA&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=RoP1YumC
>>> XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4Dpcty
>>> XPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKR
>>> o10RsZ8&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__cyberph
>>> one.github.io_doc_web_yasmin.html&d=DwICAg&c=RoP1YumCXCgaWH
>>> vlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>>> PkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-exDmX5IjKRo10RsZ
>>> 8&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.op
>>> enid.net_mailman_listinfo_openid-2Dspecs-2Dfapi&d=DwICAg&c=R
>>> oP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWN
>>> y4DpctyXPpuYqPkAI1aLcLN4KZNA&m=43ChkaJn0AI1162Dlg47a0yRs-ex
>>> DmX5IjKRo10RsZ8&s=RsGWklKg4SMG8_KQR0ahMcV9gnDd-zQEMNDW-RArMhw&e=
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

Dave Tonge
[image: Moneyhub Enterprise]
10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Momentum Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Momentum Financial Technology is entered on the
Financial Services Register (FRN 561538) at fca.org.uk/register. Momentum
Financial Technology is registered in England & Wales, company registration
number 06909772 © . Momentum Financial Technology Limited 2016. DISCLAIMER:
This email (including any attachments) is subject to copyright, and the
information in it is confidential. Use of this email or of any information
in it other than by the addressee is unauthorised and unlawful. Whilst
reasonable efforts are made to ensure that any attachments are virus-free,
it is the recipient's sole responsibility to scan all attachments for
viruses. All calls and emails to and from this company may be monitored and
recorded for legitimate purposes relating to this company's business. Any
opinions expressed in this email (or in any attachments) are those of the
author and do not necessarily represent the opinions of Momentum Financial
Technology Limited or of any other group company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20171114/d40c109d/attachment.html>

More information about the Openid-specs-fapi mailing list