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

Ralph Bragg ralph.bragg at raidiam.com
Sun Sep 27 06:40:08 UTC 2020


Andres,

Have a look at the OBIE Registration Authority and PKI. The OBIE core model was originally designed as a trust framework that included a PKI CA, RA and a Federation services provider that is now responsible for all trust services provision and management including the hosting of key sets, client management and registration. As the U.K. is leaving the EU the EBA has instructed all qtsp to revoke eidas certificates for U.K. participants in practice this will actually have little impact on the U.K. ecosystem from a technical view point.

The model that you’re talking about is the same model that now forms the backbone of Australia, U.K and Brazil where these systems directories are either directly run and controlled by the National Competent Authority (like the ACCC in Australia) or by proxy like the obie.

The same model and technology architecture is being used by several private trust networks in different regions as well.

I agree with your points regarding the significant issues and risks that exist in the eidas framework. The disconnect between registration authority, the trust list management, the PKI standards / policies / practice statements and most importantly the National competent authorities authorisation information and accreditation.

What I’m still finding surprising is that participants in this space from Europe haven’t lifted the covers under the obie curtain to see that these core issues were identified more than 3 years ago and that the obie trustframework was designed to address them from the outset.

Happy to take you through the services and model at any time.

RB



Ralph Bragg
Raidiam Services Ltd

Sent from a mobile device. Please excuse brevity and typos.
________________________________
From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Sent: Sunday, September 27, 2020 7:24:19 AM
To: Francis Pouatcha <fpo at adorsys.de>; FAPI Working Group List <openid-specs-fapi at lists.openid.net>
Cc: Anders Rundgren <anders.rundgren.net at gmail.com>
Subject: Re: [Openid-specs-fapi] : Dependencies on the OBE Registry

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/

_______________________________________________
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/20200927/5e9e4134/attachment-0001.html>


More information about the Openid-specs-fapi mailing list