<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Francis,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">See here for the OBIE DCR Spec.<o:p></o:p></span></p>
<p class="MsoNormal"><a href="https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement">https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement</a><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">It supports both a federation provider issued Software Statement Assertion and a Self Signed Software Statement Assertion and is an example of a DCR request sent as a JWT to bind both the SSA and
 the Request together.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The same approach can be achieved by using standard DCR (JSON) with ecosystem defined ‘initial access token’ as a JWT provided the request is sent over a tamper resistant transport channel such as
 an Mutually Authenticated TLS channel where both parties are using QWACs to identify each other.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Rgds,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">RB<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Ralph Bragg via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Reply to: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Date: </b>Friday, 31 July 2020 at 06:03<br>
<b>To: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Ralph Bragg <ralph.bragg@raidiam.com>, Francis Pouatcha <fpo@adorsys.de><br>
<b>Subject: </b>Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Francis,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are two approaches. 1. Sign the entire registration request. Look a the obie dynamic client registration approach for an example of how this is performed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2. Craft and define an “initial access token” which can be defined as a jwt that a tpp can use as part of registration. I have examples of both approaches if you drop me a line.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The obie is publishing a list of trusted qtsp certificates issuing and I believe the root authorities as well they is created by processing the EU list of trust listed.  banks should have no excuses for not being able to determine the set
 of issuing authorities to trust up front.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Kind Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ralph <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Francis Pouatcha via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Sent:</b> Friday, July 31, 2020 3:09:15 AM<br>
<b>To:</b> Openid-specs Fapi <openid-specs-fapi@lists.openid.net><br>
<b>Cc:</b> Francis Pouatcha <fpo@adorsys.de><br>
<b>Subject:</b> [Openid-specs-fapi] PSD2 - FAPI Client Registration</span> <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">In our attempt to use FAPI to implement the NextGenPSD2 oAuth approach, we are facing the following problem.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The PSD2 trust framework assumes each ASPSP maintains the list of legitimated certification authorities (rootCAs). This is, regulators expect ASPSP to accept requests from any licensed TPP that present a valid QWAC/QSealC certificate.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We have been looking for a way to use dynamic client registration to allow the TPP to register with ASPSP's OP/AS prior to sending their first requests.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">OP can get access to TPP's authenticated information:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- If TPP uses mTLS (QWAC) at the OP interface.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- If TPP uses QSealC to sign the client registration request, seems to be the best approach, as it also provides non repudiation.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Request Signature:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Alt-1: I prefer signing the whole http request (see <a href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/</a>). Not sure
 if this is covered by FAPI.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Alt-2: QSealC could be used to produce a private_key_jwt that will be included to the registration request. QSealC can be added to the token, to avoid pre-registration. Digest of the request body could be added to the private_key_jwt to
 provide for non repudiation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What am I missing? Are we still in the scope of OIDC/FAPI or getting out of bound?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks in advance for feedback.<o:p></o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Francis Pouatcha<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Co-Founder and Technical Lead<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">adorsys GmbH & Co. KG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>