<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="ltr">
<div></div>
<div>
<div>
<div>Andres,</div>
<div><br>
</div>
<div style="direction: ltr;">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.</div>
<div><br>
</div>
<div style="direction: ltr;">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.</div>
<div><br>
</div>
<div dir="ltr">The same model and technology architecture is being used by several private trust networks in different regions as well. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Happy to take you through the services and model at any time.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">RB</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature">
<div style="direction: ltr;">Ralph Bragg</div>
<div style="direction: ltr;">Raidiam Services Ltd</div>
<div><br>
</div>
<div style="direction: ltr;">Sent from a mobile device. Please excuse brevity and typos.</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Anders Rundgren via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Sent:</b> Sunday, September 27, 2020 7:24:19 AM<br>
<b>To:</b> Francis Pouatcha <fpo@adorsys.de>; FAPI Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc:</b> Anders Rundgren <anders.rundgren.net@gmail.com><br>
<b>Subject:</b> Re: [Openid-specs-fapi] : Dependencies on the OBE Registry</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 2020-09-27 03:45, Francis Pouatcha wrote:<br>
> CT Logs are the way to go! But as you know, NCA are always a couple of years behind.<br>
<br>
Hi Francis,<br>
<br>
The core suggestion is removing two [in my opinion redundant] parties from the plot; eIDAS issuers and the OBE registry.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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>
<br>
BR<br>
AR<br>
<br>
> <br>
> On Thu, Sep 24, 2020 at 5:21 AM Anders Rundgren via Openid-specs-fapi <openid-specs-fapi@lists.openid.net <<a href="mailto:openid-specs-fapi@lists.openid.net">mailto:openid-specs-fapi@lists.openid.net</a>>> wrote:<br>
> <br>
>     On 2020-09-24 10:56, Freddi Gyara wrote:<br>
>     Thanx Freddy!<br>
> <br>
>     Let me briefly comment on your response.<br>
> <br>
>     First off, I'm not suggesting this as the next immediate step.<br>
> <br>
> <br>
>      > Unfortunately, NCAs do not have the technical or process capability of maintaining a PKI and a proper electronic register.<br>
> <br>
>     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.<br>
> <br>
>      ><br>
>      > MTLS is convenient to implement - there is significant expertise in the industry, lots of vendor support - both through HSMs and hardware edge devices.<br>
> <br>
>     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.<br>
> <br>
>     If you have a link to the current NCA-TPP-eIDAS certification process, I would very much appreciate it.<br>
> <br>
> <br>
>      > A similar level of understanding, vendor support, tooling and expertise just does not exist around signature based solutions.<br>
> <br>
>     I see.<br>
> <br>
>      ><br>
>      > I agree with you, that non-MTLS, signature based systems are the direction that we should be travelling in.<br>
> <br>
>     Good!<br>
> <br>
>     Regards,<br>
>     Anders<br>
> <br>
> <br>
>      ><br>
>      > -----Original Message-----<br>
>      > From: Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net">mailto:openid-specs-fapi-bounces@lists.openid.net</a>>> On Behalf Of Anders Rundgren via Openid-specs-fapi<br>
>      > Sent: 24 September 2020 07:38<br>
>      > To: FAPI Working Group List <openid-specs-fapi@lists.openid.net <<a href="mailto:openid-specs-fapi@lists.openid.net">mailto:openid-specs-fapi@lists.openid.net</a>>><br>
>      > Cc: Anders Rundgren <anders.rundgren.net@gmail.com <<a href="mailto:anders.rundgren.net@gmail.com">mailto:anders.rundgren.net@gmail.com</a>>><br>
>      > Subject: External : [Openid-specs-fapi] Dependencies on the OBE Registry<br>
>      ><br>
>      > Having a central registry with TPPs seem natural until you are faced with the scaling issues.<br>
>      ><br>
>      > There is presumably a limited set of National Competent Authorities (NCAs) which could be a logical foundation for a distributed registry.<br>
>      ><br>
>      > To make this work each TPP request would contain a URL to an "Authority Record" hosted by its NCA.<br>
>      ><br>
>      > Authority Records would preferably be signed by the NCAs and be updated on a periodic basis to cope with changes including blocking misbehaving TPPs.<br>
>      ><br>
>      > 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.<br>
>      ><br>
>      > 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 :)<br>
>      ><br>
>      > thanx,<br>
>      > Anders<br>
>      ><br>
>      > _______________________________________________<br>
>      > Openid-specs-fapi mailing list<br>
>      > Openid-specs-fapi@lists.openid.net <<a href="mailto:Openid-specs-fapi@lists.openid.net">mailto:Openid-specs-fapi@lists.openid.net</a>><br>
>      > <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
>      ><br>
>      ><br>
>      > Please consider the environment before printing this email.<br>
>      ><br>
>      > 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.<br>
>      ><br>
>      > 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 (<a href="https://www.openbanking.org.uk/privacy-policy">https://www.openbanking.org.uk/privacy-policy</a>).<br>
>      ><br>
> <br>
>     _______________________________________________<br>
>     Openid-specs-fapi mailing list<br>
>     Openid-specs-fapi@lists.openid.net <<a href="mailto:Openid-specs-fapi@lists.openid.net">mailto:Openid-specs-fapi@lists.openid.net</a>><br>
>     <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Francis Pouatcha<br>
> Co-Founder and Technical Lead<br>
> adorsys GmbH & Co. KG<br>
> <a href="https://adorsys-platform.de/solutions/">https://adorsys-platform.de/solutions/</a><br>
<br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
Openid-specs-fapi@lists.openid.net<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</div>
</span></font></div>
</body>
</html>