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

[Ralph Bragg]

Cheers Brian for this - Can we get these raised as issues / discussion points separately (unless they’re accepted as tabled).
I would really like to support in particular:

Headers:
+1 on removing the ‘x-‘ it was a mistake the first time around but it had snuck into implementations.

Dpop:
Dpop support would be great as it would potentially give an avenue for fapi compliant mobile based confidential clients that can’t rely on mtls.

RB

From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Brian Campbell via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Reply to: FAPI Working Group List <openid-specs-fapi at lists.openid.net>
Date: Wednesday, 18 November 2020 at 15:41
To: FAPI Working Group List <openid-specs-fapi at lists.openid.net>
Cc: Brian Campbell <bcampbell at pingidentity.com>
Subject: Re: [Openid-specs-fapi] FAPI 2.0 Attacker Model and Baseline: Implementer's Draft?

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

"... x-fapi-auth-date ... " etc
I'll note that x- naming is not what the cool kids are doing these days https://tools.ietf.org/html/rfc6648

"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<mailto: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<mailto: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/fcfc276d/attachment-0001.html>