<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">
<div></div>
<div data-ogsc="" style="">
<div dir="ltr">Another quick one, in the bottom Section on Cryptography and Secrets In bass line there is mention of “symmetric credentials” being permitted. But I couldn’t see anywhere in the requirements for AS that they should be supported. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">If there’s a need can it be stated? (I’ll raise a ticket). Additionally for advanced profile this clause, if it’s still required, should be assymetric only no?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Will raise a ticket on advanced for that decision as well.</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature"></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> Torsten Lodderstedt <torsten@lodderstedt.net><br>
<b>Sent:</b> Saturday, June 6, 2020 10:09:22 AM<br>
<b>To:</b> Ralph Bragg <ralph.bragg@raidiam.com><br>
<b>Cc:</b> Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Subject:</b> Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses</font>
<div> </div>
</div>
<div dir="auto">
<div dir="ltr">I also suggest we document what metadata values AS and client are supposed to use, e.g. there will be the metadata parameter <span style="color:rgb(33,37,41); font-family:SFMono-Regular,Menlo,Monaco,Consolas,"Liberation Mono","Courier New",monospace; font-size:12.25px">require_pushed_authorization_requests </span>to
 let the AS indicate it supports pushed authorization requests only (<a href="https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M/">https://mailarchive.ietf.org/arch/msg/oauth/S76ODyZkHPSA6L69yyx08BuEP5M/</a>).</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">A FAPI2 compliant AS must set this value to true.</div>
<div dir="ltr"><br>
<blockquote type="cite">Am 06.06.2020 um 10:55 schrieb Ralph Bragg <ralph.bragg@raidiam.com>:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
 <style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:Calibri}
@font-face
        {font-family:"Helvetica Neue"}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
a:link, span.x_MsoHyperlink
        {color:blue;
        text-decoration:underline}
span.x_EmailStyle19
        {font-family:"Calibri",sans-serif;
        color:windowtext}
.x_MsoChpDefault
        {font-size:10.0pt}
@page WordSection1
        {margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.x_WordSection1
        {}
-->
</style>
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="">Hi Daniel,</span></p>
<p class="x_MsoNormal"><span style=""> </span></p>
<p class="x_MsoNormal"><span style="">In addition to Torstens comments, and if we’re looking for backwards combability, do we care or want to mandate that the id_token from the front channel is ONLY used for code binding. Sub is a mandatory property of the
 id_token and as such required, to prevent any leakage of any information useful to a potential attacker should the sub property explicitly be made pairwise or some other value deliberately not related to the resource owner / subject.</span></p>
<p class="x_MsoNormal"><span style=""> </span></p>
<p class="x_MsoNormal"><span style="">Kind Regards,</span></p>
<p class="x_MsoNormal"><span style="">Ralph</span></p>
<p class="x_MsoNormal"><span style=""> </span></p>
<p class="x_MsoNormal"><span style=""> </span></p>
<p class="x_MsoNormal"><span style=""> </span></p>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="x_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 Torsten Lodderstedt 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>Saturday, 6 June 2020 at 09:36<br>
<b>To: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Torsten Lodderstedt <torsten@lodderstedt.net><br>
<b>Subject: </b>Re: [Openid-specs-fapi] FAPI 2 Advanced Profile / Recommendations for signing resource requests/responses</span></p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">Hi Daniel,</p>
</div>
<div>
<p class="x_MsoNormal"><br>
<br>
</p>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<p class="x_MsoNormal" style="margin-bottom:12.0pt">Am 05.06.2020 um 10:20 schrieb Daniel Fett via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>:</p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<div>
<p>Hi all,</p>
<p>I prepared a first (rough) draft of the FAPI 2 Advanced profile and would welcome your feedback:
<a href="https://bitbucket.org/openid/fapi/src/c28fc020e7ab9377d96501f2b4daa9a9da8f2128/FAPI_2_0_Advanced_Profile.md?at=danielfett%2Ffapi2%2Fadvanced">
https://bitbucket.org/openid/fapi/src/c28fc020e7ab9377d96501f2b4daa9a9da8f2128/FAPI_2_0_Advanced_Profile.md?at=danielfett%2Ffapi2%2Fadvanced</a></p>
</div>
</blockquote>
<div>
<p class="x_MsoNormal">thanks for preparing the draft!</p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal">Here are my comments:</p>
</div>
<div>
<p class="x_MsoNormal">- <span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">[@I-D.lodderstedt-oauth-par] should refer to the WG draft</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">- „ shall support at least one of the following methods to sign the authorization response:“</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">I think the AS must support at least one mode for interoperability reasons. I think this should be JARM and ID token may be supported (for the
 purpose of this profile) for backward compatibility reasons.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">„</span><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D">OPEN QUESTION: how to handle userinfo response type selection?
 OIDC core says: depends on client registration“ I think that's fine. We use the same philosophy for all sorts of request and response signing. It’s determined by client registration parameters + general deployment metadata (what is generally supported/expected).</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D">- „<span style="background:white">The FAPI 2.0 endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated
 with the submitted access token.“ - RSs also initiate actions (eg payments), that’s one important reason for requiring non-repudiation. I suggest to add something like „.... that perform sensitive actions and return protected information for the resource owner
 ...“</span></span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white"><br>
<br>
</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">best regards,</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:10.5pt; font-family:"Helvetica Neue"; color:#172B4D; background:white">Torsten.</span></p>
</div>
<blockquote style="margin-top:5.0pt; margin-bottom:5.0pt">
<div>
<p>One open question is whether we can give recommendations regarding resource request and response signing. We currently have
<a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md">
https://bitbucket.org/openid/fapi/src/master/Financial_API_HTTP_Signing.md</a> which lists "typical requirements" but does not give concrete advice.</p>
<p>eTSI is developding JAdES and there is some work ongoing in the IETF HTTP group as well.</p>
<p>What are other options that we should take a look at?</p>
<p>-Daniel</p>
<p class="x_MsoNormal">_______________________________________________<br>
Openid-specs-fapi mailing list<br>
Openid-specs-fapi@lists.openid.net<br>
http://lists.openid.net/mailman/listinfo/openid-specs-fapi</p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</body>
</html>