<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Anders,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4 Jun 2020, at 09:41, Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" class="">anders.rundgren.net@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2020-06-04 10:18, Ralph Bragg via Openid-specs-fapi wrote:<br class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">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.<br class=""></div></div></blockquote></div><br class=""><div class="">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?</div><div class=""><br class=""></div><div class="">( <a href="https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf" class="">https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf</a> 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?)</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""></div></body></html>