<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Thanks Torsten,<br>
</p>
<p><br>
</p>
<p>My initial thoughts:<br>
</p>
<ul dir="" class="">
<li>The functional payloads i.e the "What" seems to be the focus, unsurprisingly there's a lot of overlap with OB's specs (multiple bodies are defining the same standards across Europe).<br>
</li><li>The "How" still has a huge way to go to be properly specified.<br>
<ul>
<li>No Detailed Security Profile... just use OAuth 2.0?<br>
</li><li>No MA / Certificate Validation / Role Extraction Process Detailed for how parties are to use Certs.<br>
</li><li>No validation / confirmation of how the QTSP's need to cut certs in order for them to inter-op.<br>
</li><li>No thought given to trust framework issues when multiple parties are relying on different QTSPs how are QTSPs to become trusted by all participants.<br>
</li><li>No detailed spec of How the "request Id" is sent to the AZ for authorization? Is it the intent that this is identified by different redirect urls? Which OAuth feature are they using to convey a variable consent id from the TPP to the OAuth 2.0 AZ?<br>
</li><li>Consent management and obligations on all parties is missing entirely.<br>
</li><li>No specification for registration and onboarding / mangaement of clients. There's a reference to the original OAuth 2.0 RFC but no reference even to OAuth 2 client registration spec.<br>
</li><li>No liability model / accreditation / revocation processes for QTSP's and / or subsequently ASPSPs responsibilities to validate continued accreditation of TPP's.<br>
</li><li>The signing mechanism is leveraging cavage's HTTP signing specification but no information on how the / where the Key's are too be retrieved, what the standards are for key retrieval etc etc. Cavage's spec explicitly leaves the specification of all the
necessary bits to make an implementation work in a scheme up to the scheme. SET hasn't defined any of it.<br>
</li><li>No normative or non normative examples given for how TPP's should interact with OAuth 2.0 AZ's<br>
</li><li><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">G</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">e</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">nerally </span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">the
spec</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"> for how RP's and OAuth 2.0 AZ's communicate is currently </span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">inadequate
for this to operate as a common</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"> standard a</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">cross
the</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"> </span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">french
b</span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);">anking industry but i'm sure it will be all ironed out soon.</span><br>
</li></ul>
</li></ul>
<div>Is there another document that's missing that describes how the trust framework / security profile is going to cover the above?<br>
</div>
<div><br>
</div>
<div>It will be interesting to see how successful this is for TPP's as a standard though it is good too see that there may be some functional synergies once each TPP has technically negotiated access to each ASPSP.<br>
</div>
<div><br>
</div>
<div>Cheers,<br>
</div>
<div>Ralph<br>
</div>
<div dir="auto" style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Torsten Lodderstedt via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Sent:</b> 22 July 2017 21:32<br>
<b>To:</b> openid-specs-fapi@lists.openid.net<br>
<b>Subject:</b> [Openid-specs-fapi] SET Specs are available</font>
<div> </div>
</div>
<div>Hi all,
<div></div>
<div><br>
</div>
<div>just in case you didn't notice: <a href="https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html">https://www.stet.eu/en/news/news1/stet-psd2-api-is-now-available.html</a></div>
<div><br>
</div>
<div>kind regards,</div>
<div>Torsten.</div>
</div>
</div>
<br clear="both">
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.<BR>
</body>
</html>