[Openid-specs-fapi] FAPI 2.0 Attacker Model and Baseline: Implementer's Draft?

Brian Campbell bcampbell at pingidentity.com
Wed Nov 18 15:40:54 UTC 2020

Thanks Daniel,

These two documents are shaping up nicely and I love the relative
simplicity vs. the v1.0 stuff. That said, I do have the following feedback,
questions, comments, etc., which I believe should be addressed/discussed
before progressing the documents:

I think some introductory content in the Introduction section of Baseline
is needed. This will likely be the entry point (I think anyway?) for many
readers so some intro or context setting or something here is important.

With "shall distribute discovery metadata (such as the authorization
endpoint) via the metadata document as specified in [OIDD] and [RFC8414]"in
baseline, is the "A5 - Read Token Requests and Responses" really relevant?

A7 & A8 in the attacker model read like they are grouped in with "Attackers
at the Token Endpoint". Maybe a new heading for 'attackers at resources' or
something would organize them better?

"shall reject authorization requests sent without
[@I-D.lodderstedt-oauth-par] or authorization request parameters sent
outside of the PAR request, except for request_uri and client_id"
Request parameters outside shouldn't require rejection, rather they just
must not be relied upon so should be ignored.  The end of
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5 even talks
about why a client might send parameters duplicated outside. Also the
I-D.lodderstedt-oauth-par reference should be I-D.ietf-oauth-par.

"shall only issue sender-constrained access tokens using Mutual TLS as
described in [@!RFC8705]" and "shall support sender-constrained access
tokens using Mutual TLS as described in [@!RFC8705]"
Why not allow for DPoP too? MTLS just isn't accessible in a lot of cases
and mandating it is severely limiting the applicability of FAPI2.

"shall only issue authorization codes and refresh tokens that are
sender-constrained "
What's the intent of having this? The two previous items requiring client
auth and PKCE mean a priori that the RT is sender-constrained and the auth
code is constrained twice. But this text maybe suggests something else. Or
is redundant. I'm not sure.

"shall require the redirect_uri parameter in authorization requests and
evaluate only this parameter to ensure authenticity and integrity of the
redirect URI"
What does "evaluate only this parameter to ensure authenticity and
integrity" mean? I don't know and don't know how I'd do it. I'm guessing
this text is somehow related to wanting to allow non-static redirect URIs
to be sent in authenticated PAR. But I can't tell what it actually means or
how one would conform to this (other than requiring the redirect_uri

"... x-fapi-auth-date ... " etc
I'll note that x- naming is not what the cool kids are doing these days

"Access tokens shall be non-guessable with a minimum of 128 bits of entropy
where the probability of an attacker guessing the generated token is less
than or equal to 2^(-160) as per [@!RFC6749] section 10.10."
Should ATs be the only artifact for which we give such requirements?  There
are also RTs, auth codes, request_uri values from PAR, and maybe other
stuff I'm forgetting.

On Tue, Nov 17, 2020 at 5:25 AM Daniel Fett via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hi all,
> as discussed in last week's call, I revised the FAPI 2.0 Baseline and
> Attacker Model documents again and I think that they are in a good shape.
> I'd like to hear your feedback if we can proceed with the next steps for
> this document becoming an implementer's draft.
> These are the two documents:
> 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
> Thanks,
> Daniel
> -- https://danielfett.de
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20201118/339fb458/attachment-0001.html>

More information about the Openid-specs-fapi mailing list