[Openid-specs-fapi] FAPI 2.0

Daniel Fett fett at danielfett.de
Thu Feb 27 08:12:57 UTC 2020

Thanks for the feedback, Joseph! Answers inline.

Am 26.02.20 um 17:23 schrieb Joseph Heenan:
> Thanks Daniel!
> A few quick initial thoughts:
> "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?

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.)

> 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.

You are right, I will fix that.

> 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.

Currently, RPs need MTLS anyway for sender-constraining of the AT.
Therefore I'm not sure if RP credentials would actually make things easier.

> I think I was expecting that the baseline profile would allow public
> clients, which it doesn’t seem to.

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.

> 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?

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.

> 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.

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.

Thanks again for the feedback!


> Thanks
> Joseph
>> On 26 Feb 2020, at 15:43, Daniel Fett via Openid-specs-fapi
>> <openid-specs-fapi at lists.openid.net
>> <mailto:openid-specs-fapi at lists.openid.net>> wrote:
>> Hi all,
>> Based on our previous discussions regarding "FAPI Evolution" I
>> prepared drafts for the first two documents of FAPI 2.0:
>> https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Attacker_Model.md
>> https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md
>> (I attached the respective HTML versions to this mail, let's see if
>> the mailing list eats them or not.)
>> In the Baseline profile document, I added a table showing the
>> differences to FAPI 1.0 R/W.
>> There are some open points collected towards the bottom of the
>> document. There are also no security considerations right now.
>> Please read these documents and give feedback here or file issues on
>> bitbucket.
>> -Daniel
>> <FAPI_2_0_Baseline_Profile.html><FAPI_2_0_Attacker_Model.html>_______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> <mailto:Openid-specs-fapi at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200227/7047d3a5/attachment-0001.html>

More information about the Openid-specs-fapi mailing list