<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div>
<div style="direction:ltr">All,</div>
<div><br>
</div>
<div style="direction:ltr">There was a meeting of the major standards bodies last week with ETSI coordinating. JWS detached and not detached will almost certainly be one of the agreed formats for AdES and subsequently message signing for PSD2.</div>
<div><br>
</div>
<div style="direction:ltr">When the minutes are published I’ll share.</div>
<div><br>
</div>
<div style="direction:ltr">Given that Cavage 11 includes the following. </div>
<div style="direction:ltr">WARNING: DO NOT IMPLEMENT THIS SPECIFICATION AND PUSH THE CODE INTO</div>
<div style="direction:ltr">  PRODUCTION.  THIS VERSION OF THE SPECIFICATION IS ONLY FOR</div>
<div style="direction:ltr">  EXPERIMENTAL IMPLEMENTATIONS.</div>
<div><br>
</div>
<div style="direction:ltr">The Berlin group and others have had to explicitly reference version 10 to avoid using a a spec that says “don’t use this”. This doesn’t leave them a way forward with this draft. I expect that ETSI will look at the desirable properties
 of the Cavages draft and try and come up with something that has the same characteristics.</div>
<div><br>
</div>
<div style="direction:ltr">RB</div>
</div>
<div><br>
</div>
<div class="x_ms-outlook-ios-signature"></div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_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 Anders Rundgren via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Sent:</b> Sunday, September 29, 2019 7:20:33 AM<br>
<b>To:</b> Financial API Working Group List <Openid-specs-fapi@lists.openid.net><br>
<b>Cc:</b> Anders Rundgren <anders.rundgren.net@gmail.com><br>
<b>Subject:</b> [Openid-specs-fapi] Next step(s) for FAPI?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">Dear FAPIers,<br>
<br>
Apparently the (in)famous <a href="https://datatracker.ietf.org/doc/draft-cavage-http-signatures/">
https://datatracker.ietf.org/doc/draft-cavage-http-signatures/</a> scheme has more or less become a de-facto standard.<br>
<br>
Convincing the Berlin Group to change their NextGenPSD2 API will probably not happen since no standardized alternative is available and OBIE's current signature solution isn't REST compliant.<br>
<br>
Anyway, there are other things FAPI could do to gather more interest.  It may be worthwhile collecting such and then decide where to go.<br>
<br>
Here are a few known (and published) candidates:<br>
1. An HTTP signature scheme that supports JSON serialization and embedding.<br>
2. A scheme for enriching authorization requests.<br>
3. A scheme for using FAPI locally in banks.<br>
<br>
I'm currently plotting with #3 because it should be 100% backward compatible, while still being potentially quite useful. "Low hanging fruit" :)  Note though that OAuth2 is not really my area of expertize so it would be great if this was a FAPI project!<br>
<br>
WDYT?<br>
<br>
Anders<br>
<br>
<a href="https://github.com/cyberphone/swedbank-psd2-saturn">https://github.com/cyberphone/swedbank-psd2-saturn</a><br>
<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>
</body>
</html>