[Openid-specs-fapi] High level text on CA trust models for financial apis

[Tom Jones]

Closed system security should be the exclusive domain of the closed system
administrator.

But i cannot understand how a banking system can be consider closed. Isn't
every person and company on the internet a potential customer.
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.
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.
If not part of the browser trust list, i could not even do discovery
endpoint without the cert on my own dev box.
That would be problematic for me personally.

closed https subsystems are much harder to administer than you might
imagine.


Peace ..tom

On Thu, May 17, 2018 at 6:00 AM, Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Dear FAPI WG,
>
> 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.
>
> I'd also be grateful if anyone could point me to existing text that seeks
> to describe these different models.
>
> Thanks
>
> Dave
>
> ----
>
> # Certificate Issuance and Verification
>
> Key to the authentication and identity characteristics of TLS is the
> issuance and verification of certificates. There are a number of different
> approaches that can be applied to financial APIs - each with a different
> trust model.
>
> ## Standard website certificates issued by globally trusted certificate
> authorities
>
> 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.
>
> 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.
>
> 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.
>
> ## Regional trust frameworks, such as eIDAS in the EU
>
> 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.
>
> ## Federation Operators
>
> 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.
>
> --
> Dave Tonge
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180517/c336cbea/attachment.html>