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

Tom Jones thomasclinganjones at gmail.com
Fri May 18 14:50:52 UTC 2018

i agree with you on your points. I would just like everyone to understand
the pain for the developers and implementors.

Peace ..tom

On Fri, May 18, 2018 at 2:24 AM, Dave Tonge <dave.tonge at momentumft.co.uk>

> 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
> [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/58007273/attachment.html>

More information about the Openid-specs-fapi mailing list