[Openid-specs-fapi] Last Call (was: Berling group consultation response table)
nat at sakimura.org
Tue Nov 14 11:31:13 UTC 2017
Thanks Anders for the comment. Having said that, I do not know how to
act on it.
As far as signHTTP is concerned, what I have on the comment sheet seems
to be pretty much we can reasonable write as the working group. Many
people do not understand the difference between different tracks of RFC
and the difference between the individual drafts and IETF drafts. So,
the comment is pointing it out.
I have tried to put the collected comments on the comment sheet.
We are going to send it off tomorrow, so please review it asap.
Research Fellow, Nomura Research Institute
Chairman of the Board, OpenID Foundation
On 2017-11-13 18:53, Anders Rundgren via Openid-specs-fapi wrote:
> On 2017-11-13 10:25, Phil Hunt (IDM) wrote:
>> Fwiw. We looked at signed http requests as part of proof of possession
>> 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.
>>> 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?
>>> "4.2 [signHTTP] is not a standard nor it is on the way to become
>>> It has not and is not going under the rigor of the
>>> standardization process"
>>> FWIW, the STET PSD2 API
>>> 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:
>>>> 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
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
More information about the Openid-specs-fapi