<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 - a few responses inline:<div class=""><br class=""></div><div class="">(Any points I removed I agree with your response - thanks!)<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 27 Feb 2020, at 08:12, Daniel Fett <<a href="mailto:fett@danielfett.de" class="">fett@danielfett.de</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="">
<div class="moz-cite-prefix">Thanks for the feedback, Joseph!
Answers inline.<br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Am 26.02.20 um 17:23 schrieb Joseph
Heenan:<br class="">
</div>
<blockquote type="cite" cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" 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>
</blockquote><p class="">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></div></div></blockquote><div>Good answer :-) I think it’s also a reasonable position given I believe we’re not aware of deployments of FAPI-R.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com" class=""><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 class="">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 class=""></p></div></div></blockquote>Good point.</div><div><br class=""></div><div>I think it would be interesting to discuss whether dPoP would meet the goals and is something we could include as an alternative. DPoP feels to me to be easier for clients than MTLS (and potentially servers too - the certification team has seen a LOT of people struggle to get MTLS working on production systems due to issues with WAFs and similar that are required for PCI compliance).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:8C5F78D2-392E-4706-9718-7B0B80137F65@authlete.com" class=""><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 class="">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></div></div></blockquote></div>Interesting, I never noticed that before. We may want to make the language a little clearer in both places I guess.</div><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""></div></body></html>