<div dir="ltr">Hello Ralph,<div><br></div><div>The draft ETSI JAdES standard is what I refer to with "JSON Web Signature Profile for Open Banking" that is designed to be JAdES compliant.. Berlin Group is also behind the standard, as they are listed among the contributors.</div><div><br></div><div>Although the OBIE approach is criticized, it is the only option I met so far that provides non repudiation for DCR. </div><div><br></div><div>Considering heavy regulation of the financial industry, not covering non repudiation is not an option.</div><div><br></div><div>Best regards.</div><div>/Francis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 1, 2020 at 3:12 PM Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com">ralph.bragg@raidiam.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div></div>
<div>
<div>Hi Francis,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I can only take partial credit for its adoption in the obie specifications the other credit belongs to the talented Pam Dingle. The draft ETSI JAdES standard for payload signing should also be consulted (though it’s a detached format for signing)
if you want something that’s future proof and a European wide standard for JSON payload signing. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">All standards bodies Are being encouraged to adopt JAdES by ETSI when it is published so check if that is still the intention for Berlin group. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I should also point out that the obie approach isn’t necessarily universally liked by this community as the inner jwt has to be unpacked to obtain the key locations in order to validate the outer payload. It’s not an ietf or oidf standard however
there is wide spread support for processing this request format from all major idps. </div>
<div><br>
</div>
<div id="gmail-m_6494092242034630866ms-outlook-mobile-signature">
<div style="direction:ltr">Ralph Bragg</div>
<div style="direction:ltr">Raidiam Services Ltd</div>
<div dir="ltr"><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%">
<div id="gmail-m_6494092242034630866divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Francis Pouatcha <<a href="mailto:fpo@adorsys.de" target="_blank">fpo@adorsys.de</a>><br>
<b>Sent:</b> Friday, July 31, 2020 10:35:16 PM<br>
<b>To:</b> Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a>><br>
<b>Cc:</b> Financial API Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Subject:</b> Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hello Ralph,
<div><br>
</div>
<div>excellent work done here (<a href="https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement" target="_blank">https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement</a>).
realy! We can build on top of this.</div>
<div><br>
</div>
<div>For authentication of TPP with ASPSP's AS, we will use: tls_client_auth. This is included.</div>
<div><br>
</div>
<div>OBIE signing the entire registration request provides for non repudiation for the registration call. This is a great first step. If we can add the QSealC to the header of the request, we will be complete here.</div>
<div><br>
</div>
<div>Last part missing would be the non repudiation for all other back channel requests from TPP to ASPSP's AS.</div>
<div><br>
</div>
<div>To FAPI Working Group:</div>
<div><br>
</div>
<div>IT makes sense to add the option of having (all) requests from TPP to ASPSP's AS signed (e.g.: QSealC). We could call this authentication method: "signed_http_request".<br>
</div>
<div><br>
</div>
<div>The signature scheme supported by the AS could be published with AS metadata. IT could be:</div>
<div>- JSON Web Signature Profile for Open Banking (See EBA Clearing)</div>
<div>- draft-ietf-httpbis-message-signatures</div>
<div>- Or any other scheme providing non repudiation over HTTP messages.</div>
<div><br>
</div>
<div>The AS metadata could define the header field where to put the signature certificate (Like in NextGenPSD2 the TPP-Signature-Certificate).</div>
<div><br>
</div>
<div>Canonicalization shall also be defined by the chosen signature standard.</div>
<div><br>
</div>
<div>Does this look like a change request to FAPI?</div>
<div><br>
</div>
<div>Best regards</div>
<div>/Francis</div>
<div><br>
</div>
<p><u></u></p>
</div>
<br>
<div>
<div dir="ltr">On Fri, Jul 31, 2020 at 2:07 AM Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p><span>Hi Francis,<u></u><u></u></span></p>
<p><span><u></u> <u></u></span></p>
<p><span>See here for the OBIE DCR Spec.<u></u><u></u></span></p>
<p><a href="https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement" target="_blank">https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html#software-statement</a><u></u><u></u></p>
<p><span><u></u> <u></u></span></p>
<p><span>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.<u></u><u></u></span></p>
<p><span><u></u> <u></u></span></p>
<p><span>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. <u></u><u></u></span></p>
<p><span><u></u> <u></u></span></p>
<p><span>Rgds,<u></u><u></u></span></p>
<p><span>RB<u></u><u></u></span></p>
<p><span><u></u> <u></u></span></p>
<p><span><u></u> <u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm">
<p><b><span style="font-size:12pt;color:black">From: </span>
</b><span style="font-size:12pt;color:black">Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a>> on behalf of Ralph Bragg via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Reply to: </b>Financial API Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Date: </b>Friday, 31 July 2020 at 06:03<br>
<b>To: </b>Financial API Working Group List <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Cc: </b>Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a>>, Francis Pouatcha <<a href="mailto:fpo@adorsys.de" target="_blank">fpo@adorsys.de</a>><br>
<b>Subject: </b>Re: [Openid-specs-fapi] PSD2 - FAPI Client Registration<u></u><u></u></span></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<p>Hi Francis,<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>Kind Regards,<u></u><u></u></p>
</div>
<div>
<p>Ralph <u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
</div>
<div>
<p><u></u> <u></u></p>
</div>
</div>
<div align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="gmail-m_6494092242034630866x_gmail-m_3242503498201068856divRplyFwdMsg">
<p><b><span style="color:black">From:</span></b><span style="color:black"> Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a>> on behalf of Francis
Pouatcha via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Sent:</b> Friday, July 31, 2020 3:09:15 AM<br>
<b>To:</b> Openid-specs Fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>><br>
<b>Cc:</b> Francis Pouatcha <<a href="mailto:fpo@adorsys.de" target="_blank">fpo@adorsys.de</a>><br>
<b>Subject:</b> [Openid-specs-fapi] PSD2 - FAPI Client Registration</span> <u></u><u></u></p>
<div>
<p> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p>In our attempt to use FAPI to implement the NextGenPSD2 oAuth approach, we are facing the following problem.
<u></u><u></u></p>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>OP can get access to TPP's authenticated information:<u></u><u></u></p>
</div>
<div>
<p>- If TPP uses mTLS (QWAC) at the OP interface.<u></u><u></u></p>
</div>
<div>
<p>- If TPP uses QSealC to sign the client registration request, seems to be the best approach, as it also provides non repudiation.<u></u><u></u></p>
</div>
<div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>Request Signature:<u></u><u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p>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.<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>What am I missing? Are we still in the scope of OIDC/FAPI or getting out of bound?<u></u><u></u></p>
</div>
<div>
<p><u></u> <u></u></p>
</div>
<div>
<p>Thanks in advance for feedback.<u></u><u></u></p>
</div>
<p>-- <u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p>Francis Pouatcha<u></u><u></u></p>
</div>
<div>
<p>Co-Founder and Technical Lead<u></u><u></u></p>
</div>
<div>
<p>adorsys GmbH & Co. KG<u></u><u></u></p>
</div>
<div>
<p><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>Francis Pouatcha</div>
<div>Co-Founder and Technical Lead</div>
<div>adorsys GmbH & Co. KG</div>
<div><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Francis Pouatcha</div><div>Co-Founder and Technical Lead</div><div>adorsys GmbH & Co. KG</div><div><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a></div></div></div></div></div></div></div></div></div></div>