<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thanks for the feedback, Joseph!
Answers inline.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 26.02.20 um 17:23 schrieb Joseph
Heenan:<br>
</div>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Thanks Daniel!
<div class=""><br class="">
</div>
<div class="">A few quick initial thoughts:</div>
<div class=""><br class="">
</div>
<div class="">"2.4. Differences to FAPI 1.0” the first column
doesn’t seem quite right - as this is the base line profile
should it be comparing against FAPI-R rather than FAPI-RW?</div>
</blockquote>
<p>It is based off FAPI-RW. To reach the security goals, it is
easier to start from RW. If we find that we can give some leeway,
we can reintroduce features from R. (Baseline and Advanced are not
just new names for R and RW.)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<div class=""><br class="">
</div>
<div class="">If it is comparing against FAPI-RW, then FAPI-RW
already only allows asymmetric client auth, and allows both
private_key_jwt and MTLS client auth.</div>
</blockquote>
<p>You are right, I will fix that.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<div class=""><br class="">
</div>
<div class="">I have some concerns about FAPI 2.0 baseline only
allowing MTLS for client authentication.As it stands today this
still adds quite a burden on RPs, compared to FAPI-R which did
allow simple RP credentials.</div>
</blockquote>
<p>Currently, RPs need MTLS anyway for sender-constraining of the
AT. Therefore I'm not sure if RP credentials would actually make
things easier.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<div class=""><br class="">
</div>
<div class="">I think I was expecting that the baseline profile
would allow public clients, which it doesn’t seem to.</div>
</blockquote>
<p>I'm not currently seeing how we can achieve the security goals
with public clients. But this is certainly something we should
discuss in more detail.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<div class=""><br class="">
</div>
<div class="">I’m surprised to see the baseline spec requiring
encrypted id_token support from clients - I think the idea is
that id_tokens are only sent in the back channel, so encryption
seems unnecessary?</div>
</blockquote>
<p>Indeed, there is no need for encryption here. We can even skip
signatures if they are only exchanged in the back channel. (We
need signing in Advanced, though.) I will fix that. <br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com">
<div class=""><br class="">
</div>
<div class="">RS Checking access tokens are not revoked ("MUST
verify that the access token is neither expired nor revoked;”)
is also very strong language in a baseline profile, and appears
to rule out the implementation choice of having short lived JWT
access tokens that cannot be revoked.</div>
</blockquote>
<p>That is actually taken from the current R spec. How I read it, it
still allows for unrevokable short-lived JWTs, since if they are
never revoked, the check always passes.</p>
<p>Thanks again for the feedback!</p>
<p>Daniel</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com"><br
class="">
<div class="">Thanks</div>
<div class=""><br class="">
</div>
<div class="">Joseph</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 26 Feb 2020, at 15:43, Daniel Fett via
Openid-specs-fapi <<a
href="mailto:openid-specs-fapi@lists.openid.net"
class="" moz-do-not-send="true">openid-specs-fapi@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class="">Hi all,</p>
<p class="">Based on our previous discussions regarding
"FAPI Evolution" I prepared drafts for the first two
documents of FAPI 2.0:</p>
<p class=""><a class="moz-txt-link-freetext"
href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md"
moz-do-not-send="true">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md</a></p>
<p class=""><a class="moz-txt-link-freetext"
href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md"
moz-do-not-send="true">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md</a></p>
<p class="">(I attached the respective HTML versions to
this mail, let's see if the mailing list eats them or
not.)</p>
<p class="">In the Baseline profile document, I added a
table showing the differences to FAPI 1.0 R/W.</p>
<p class="">There are some open points collected towards
the bottom of the document. There are also no security
considerations right now.</p>
<p class="">Please read these documents and give
feedback here or file issues on bitbucket.<br class="">
</p>
<p class="">-Daniel<br class="">
</p>
</div>
<span
id="cid:2939E65F-F715-4066-957A-F03FCD946260@sh2.org.uk"><FAPI_2_0_Baseline_Profile.html></span><span
id="cid:5D918334-0E26-44B4-953A-0906BDF3FDC4@sh2.org.uk"><FAPI_2_0_Attacker_Model.html></span>_______________________________________________<br
class="">
Openid-specs-fapi mailing list<br class="">
<a href="mailto:Openid-specs-fapi@lists.openid.net"
class="" moz-do-not-send="true">Openid-specs-fapi@lists.openid.net</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<p><br>
</p>
</body>
</html>