<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="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div>
<br><div class="gmail_quote">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.openid.net</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"><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="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="m_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>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
<br></blockquote></div><br></div>