[Openid-specs-fapi] : Dependencies on the OBE Registry

Anders Rundgren anders.rundgren.net at gmail.com
Sun Sep 27 06:24:19 UTC 2020


On 2020-09-27 03:45, Francis Pouatcha wrote:
> CT Logs are the way to go! But as you know, NCA are always a couple of years behind.

Hi Francis,

The core suggestion is removing two [in my opinion redundant] parties from the plot; eIDAS issuers and the OBE registry.

In fact, it is the opposite to eIDAS. By reducing the scope and applicability of the TPP PKI by more than 3 magnitudes you can reduce costs while improving speed and accuracy.

This is very similar to our discussions in another forum regarding user payment authorization schemes where one of the suggestions require that all components of the infrastructure (even including the "SCA device") must understand and be able to validate eIDAS certificates, while schemes like EMV an Saturn limit the trust network to the issuing bank's own clients and their cards respectively wallets.

Providing a URL to your own authority when calling other entities is the scheme used by Saturn to "emulate" something which is like a PKI for Merchants (and more).  Doing something similar with eIDAS isn't realistic due to cost and liability issues. In this case we are talking about trust networks with more than 10 million entities!

BR
AR

> 
> On Thu, Sep 24, 2020 at 5:21 AM Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
> 
>     On 2020-09-24 10:56, Freddi Gyara wrote:
>     Thanx Freddy!
> 
>     Let me briefly comment on your response.
> 
>     First off, I'm not suggesting this as the next immediate step.
> 
> 
>      > Unfortunately, NCAs do not have the technical or process capability of maintaining a PKI and a proper electronic register.
> 
>     This could eventually be provided as an "appliance" (or even as a cloud service), needing very moderate competence to run as well as integrate with the rest of the accreditation process.
> 
>      >
>      > MTLS is convenient to implement - there is significant expertise in the industry, lots of vendor support - both through HSMs and hardware edge devices.
> 
>     The technical part is fairly simple but not the way you manage it.  In this case things become quite complicated because an NCA effectively becomes an "RA" but without belonging to the issuers trust network.  This is the scalability issue behind this suggestion.  Most of the eIDAS issuers will probably go bust because dedicated trust networks work just fine.
> 
>     If you have a link to the current NCA-TPP-eIDAS certification process, I would very much appreciate it.
> 
> 
>      > A similar level of understanding, vendor support, tooling and expertise just does not exist around signature based solutions.
> 
>     I see.
> 
>      >
>      > I agree with you, that non-MTLS, signature based systems are the direction that we should be travelling in.
> 
>     Good!
> 
>     Regards,
>     Anders
> 
> 
>      >
>      > -----Original Message-----
>      > From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net <mailto:openid-specs-fapi-bounces at lists.openid.net>> On Behalf Of Anders Rundgren via Openid-specs-fapi
>      > Sent: 24 September 2020 07:38
>      > To: FAPI Working Group List <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>
>      > Cc: Anders Rundgren <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>>
>      > Subject: External : [Openid-specs-fapi] Dependencies on the OBE Registry
>      >
>      > Having a central registry with TPPs seem natural until you are faced with the scaling issues.
>      >
>      > There is presumably a limited set of National Competent Authorities (NCAs) which could be a logical foundation for a distributed registry.
>      >
>      > To make this work each TPP request would contain a URL to an "Authority Record" hosted by its NCA.
>      >
>      > Authority Records would preferably be signed by the NCAs and be updated on a periodic basis to cope with changes including blocking misbehaving TPPs.
>      >
>      > In the long-run this could also eliminate the need for separately purchasing and managing eIDAS certificates; this would rather be an integral part of the NCA accreditation process.  A TPP certificate issued by an NCA would only be useful for Open Banking.
>      >
>      > Saturn uses this scheme but only publishes "certified signature (public) keys" in Authority Records since payments do not benefit from MTLS.  Personally, I would consider shelving MTLS for the entire Open Banking system.  FIDO shows that MTLS is not necessarily a necessity :)
>      >
>      > thanx,
>      > Anders
>      >
>      > _______________________________________________
>      > Openid-specs-fapi mailing list
>      > Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>      > http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>      >
>      >
>      > Please consider the environment before printing this email.
>      >
>      > This email is from Open Banking Limited, Company Number 10440081. Our registered and postal address is 2 Thomas More Square, London, E1W 1YN. Any views or opinions are solely those of the author and do not necessarily represent those of Open Banking Limited.
>      >
>      > This email and any attachments are confidential and are intended for the above named only. They may also be legally privileged or covered by other legal rights and rules. Unauthorised dissemination or copying of this email and any attachments, and any use or disclosure of them, is strictly prohibited and may be illegal. If you have received them in error, please delete them and all copies from your system and notify the sender immediately by return email. You can also view our privacy policy (https://www.openbanking.org.uk/privacy-policy).
>      >
> 
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> 
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/



More information about the Openid-specs-fapi mailing list