<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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><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><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><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><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><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><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="">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">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">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="">Openid-specs-fapi@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-fapi<br class=""></div></blockquote></div><br class=""></div></body></html>