<div dir="ltr">Note that the FCA claims it it there to protect the user<div><a href="https://www.fca.org.uk/about/protecting-consumers">https://www.fca.org.uk/about/protecting-consumers</a><br></div><div>It has fixed up some of the language since this thread began. Now the only problem that i have with the fca docs is that the user experience in not adequate.</div><div>I would like to see fapi pt 2 be adequate from a user experience perspective.</div><div>The OAUTH spec does recognize the need for trust, but does not explain the mechanism.</div><div>I believe that any useful Financial API needs to address the need for trust, and i would like it to mandate at least something about the mechanism for obtaining that trust.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div>
<br><div class="gmail_quote">On Mon, Mar 5, 2018 at 5:05 AM, Tom Jones <span dir="ltr"><<a href="mailto:thomasclinganjones@gmail.com" target="_blank">thomasclinganjones@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">perhaps my language is not clear then.<div>As i understand it, the AS gets a grant, which actually comes from the client and responds with a token, the explicit assumption is that the user trust the OP to make that at the user's consent.</div><div>What i believe MUST be in scope for this to make any sense is that the user knows who the client is and trust the clients to act on the user's behalf.</div><div>If that is not in scope then this spec is actually meaningless from the users perspective.</div><div>I understand that is out of scope in Open ID Connect, but must be fro this profile. That is why i also added the strong ID part for the client.</div><div><br></div><div>In a nutshell:</div><div>THE USER MUST BE ABLE TO TRUST ANY ENTITY THAT ACTS ON THE USER'S BEHALF TO TAKE MONEY OUT OF THE USER ACCOUNT..</div><div>my assertion;</div><div>If that is not in scope we have failed the user.</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-973596748426353050gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Fri, Mar 2, 2018 at 3:05 PM, tomcjones via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">New issue 136: responsibility<br>
<a href="https://bitbucket.org/openid/fapi/issues/136/responsibility" rel="noreferrer" target="_blank">https://bitbucket.org/openid/f<wbr>api/issues/136/responsibility</a><br>
<br>
tomcjones:<br>
<br>
Add a clarifying comment to FAPI #2<br>
<br>
Following this profile as written is not sufficient to prove the user bears responsibility for  the security of the transaction.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid<wbr>.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-fapi</a><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>