<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks for the feedback Tom.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I should clarify that this in the context of APIs and therefore is about the identification of financial institutions and third party providers - not end-users.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">As these are API endpoints they are not expected to be opened in browsers, bur rather by "confidential client" software. I agree that there are definite maintenance issues for such systems, but they exist and do have some advantages. The main advantage from my perspective is: common issuer of "client" and "server" certificates with agreed federation rules on revocation / renewal implemented right down to the transport layer.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 May 2018 at 02:53, 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">Closed system security should be the exclusive domain of the closed system administrator.<div><br></div><div>But i cannot understand how a banking system can be consider closed. Isn't every person and company on the internet a potential customer.</div><div>Perhaps you mean for only the connex among the participants, but even there all of the sites will also need to establish HTTPS links to non-members.</div><div>I believe it will be a maintenance headache for many participants to have cert from multiple unrelated sources, unless those sources were also trusted by the major browser manufacturers.</div><div>If not part of the browser trust list, i could not even do discovery endpoint without the cert on my own dev box.</div><div>That would be problematic for me personally.</div><div><br></div><div>closed https subsystems are much harder to administer than you might imagine.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-3070091837141076745gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Thu, May 17, 2018 at 6:00 AM, Dave Tonge 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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><div class="gmail_default">Dear FAPI WG,</div><div class="gmail_default"><br></div><div class="gmail_default">Part of the work being done for the technical standard from ISO TC68 / SC9 / WG2 is high level guidance around more than just the use of OAuth and TLS. It would be great to have some feedback on the below text.</div><div class="gmail_default"><br></div><div class="gmail_default">I'd also be grateful if anyone could point me to existing text that seeks to describe these different models.</div><div class="gmail_default"><br></div><div class="gmail_default">Thanks</div><div class="gmail_default"><br></div><div class="gmail_default">Dave</div><div class="gmail_default"><br></div><div class="gmail_default">----</div><div class="gmail_default"><br></div><div class="gmail_default"># Certificate Issuance and Verification</div><div class="gmail_default"><br></div><div class="gmail_default">Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches <span style="color:rgb(34,34,34);font-family:"trebuchet ms",sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">that can be applied to financial APIs -</span> each with a different trust model.</div><div class="gmail_default"><br></div><div class="gmail_default">## Standard website certificates issued by globally trusted certificate authorities<br></div><div class="gmail_default"><br></div><div class="gmail_default">Internet Browser and Operating System providers maintain lists of globally trusted certificate authorities, the Mozilla one is widely used and is available here. A financial API provider can obtain certificates signed by one of these globally trusted certificate authorities from multiple vendors in the market, who will validate that the provider controls a domain before issuing a certificate corresponding to that domain. </div><div class="gmail_default"><br></div><div class="gmail_default">These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. <br><br></div><div class="gmail_default">One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates. If a deployment requires the use of client certificates then it may be appropriate to consider using a different trust model.</div><div class="gmail_default"><br></div><div class="gmail_default">## Regional trust frameworks, such as eIDAS in the EU<br></div><div class="gmail_default"><br></div><div class="gmail_default">The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law. </div><div class="gmail_default"><br></div><div class="gmail_default">## Federation Operators</div><div class="gmail_default"><br></div><div class="gmail_default">Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.<span class="m_-3070091837141076745HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="m_-3070091837141076745m_8871903420794730645gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:1em;font-weight:bold;line-height:1.4"><div style="color:rgb(97,97,97);font-family:'Open Sans';font-size:14px;font-weight:normal;line-height:21px"><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold"><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4"><div style="font-weight:400;color:rgb(51,51,51);line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4"><br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
</div>
<br></div></div>______________________________<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>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-size:14px;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal"><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px"><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165);text-decoration:none" target="_blank"><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border:none;padding:0px;border-radius:2px;margin:7px"></a></div><div style="padding:8px 0px"><div style="padding:8px 0px"><span style="color:rgb(0,164,183);font-size:11px">Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre, Lewins Mead, Bristol, BS1 2NT</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold"></span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold">t: </span><span style="font-size:11px;line-height:15.925px">+44 (0)117 280 5120</span><br></div><div style="color:rgb(97,97,97);font-size:14px;font-family:lato,"open sans",arial,sans-serif"><font color="#00a4b7"><span style="font-size:11px;line-height:15.925px"><br></span></font><div style="color:rgb(51,51,51);line-height:1.4"><span style="font-size:0.75em">Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). </span><span style="font-size:10.5px">Moneyhub</span><span style="font-size:0.75em"> Financial Technology is entered on the Financial Services Register </span><span style="font-size:0.75em;background-color:transparent">(FRN </span><span style="font-size:0.75em;background-color:transparent;color:rgb(0,164,183);font-weight:bold">561538</span><span style="font-size:0.75em;background-color:transparent">) at <a href="http://fca.org.uk/register" target="_blank">fca.org.uk/register</a>. </span><span style="font-size:10.5px">Moneyhub</span><span style="font-size:0.75em;background-color:transparent"> Financial Technology is registered in England & Wales, company registration number </span><span style="font-size:0.75em;color:rgb(0,164,183);font-weight:bold;background-color:transparent">06909772</span><span style="font-size:0.75em;background-color:transparent"> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:transparent"><font size="1">©</font></span><span style="font-size:0.75em;background-color:transparent"> . </span><span style="font-size:10.5px">Moneyhub</span><span style="background-color:transparent;font-size:0.75em"> Financial Technology Limited 2018. </span><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)">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.</span></div></div></div></div></div></div></div>
</div>