[Openid-specs-fapi] Issue #295: Possible support for "embedded" SCA mode (openid/fapi)
anders.rundgren.net at gmail.com
Thu Jun 4 09:21:01 UTC 2020
On 2020-06-04 11:01, Joseph Heenan wrote:
> Hi Anders,
>> On 4 Jun 2020, at 09:41, Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
>> On 2020-06-04 10:18, Ralph Bragg via Openid-specs-fapi wrote:
>>> Signing and encrypting the login token hint would protect this in transit and ensure a way that only a valid tpp could present it and that it could be decrypted by the target aspsp.
>> Supporting EMV which is one of the goals for NextGenPSD2 there is no login token hint. In fact, there's no login at all, it is rather pre-authorized payment-requests.
> Can you describe with a few lines of text (without referring to Saturn :-) ) how a protocol could address the EMV use case within FAPI or one of the other mechanisms we’re discussing please?
> ( https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf seems mostly to be rehashing OpenID’s “sub” and OAuth2’s refresh token, and I can’t see where the result differs from using those two?)
The document you are referring to is the best description I have so I can only repeat myself :)
The technical core of the idea is keeping payment applications like EMV, Saturn, FIDO, etc out of the Open Banking API.
The commercial aspect is that such applications would preferably be provided by the respective system owner.
The applications (services rather) may or may not be PSD2 compatible.
The scheme builds on using OAuth2 as binding system between these services (additional APIs) and the core API, where the former thus works like TPPs.
The only really new thing is that the applications are running with higher privileges than existing applications since they are supposed to do SCA on their own.
Making Open Banking APIs [technically] usable for any consumer payment may not be such a bad idea.
Reasonably good engineer, lousy salesman
More information about the Openid-specs-fapi