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

Dave Tonge dave.tonge at momentumft.co.uk
Fri May 18 09:24:44 UTC 2018


Thanks for the feedback Tom.

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.
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.

Dave

On 18 May 2018 at 02:53, Tom Jones <thomasclinganjones at gmail.com> wrote:

> 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
>>
>>
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 2nd Floor, Whitefriars Business Centre,
Lewins Mead, Bristol, BS1 2NT
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 561538) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 © . Moneyhub Financial Technology Limited 2018. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180518/84002fe6/attachment-0001.html>


More information about the Openid-specs-fapi mailing list