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

Dave Tonge dave.tonge at momentumft.co.uk
Thu May 17 13:00:38 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180517/84849271/attachment.html>


More information about the Openid-specs-fapi mailing list