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

Brian Campbell bcampbell at pingidentity.com
Wed Nov 18 21:40:20 UTC 2020


individual issues now filed and linked inline below

On Wed, Nov 18, 2020 at 9:41 AM Brian Campbell <bcampbell at pingidentity.com>
wrote:

> I wasn't sure if raising individual issues was appropriate or needed. But
> I'm happy to do so, if it helps facilitate the process of discussion and
> resolution.
>
> On Wed, Nov 18, 2020 at 8:51 AM Ralph Bragg <ralph.bragg at raidiam.com>
> wrote:
>
>> 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.
>>
>
https://bitbucket.org/openid/fapi/issues/337/intro-text-in-basline



>>
>> 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?
>>
>
https://bitbucket.org/openid/fapi/issues/338/a5-attacker-model



> 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?
>>
>
https://bitbucket.org/openid/fapi/issues/339/resources-token-endpoint



>
>>
>> "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.
>>
>
https://bitbucket.org/openid/fapi/issues/340/treatment-of-authorization-request



>
>>
>> "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.
>>
>
https://bitbucket.org/openid/fapi/issues/341/free-dpop



>
>>
>> "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.
>>
>
https://bitbucket.org/openid/fapi/issues/342/sender-constrained-auth-codes-refresh



>
>>
>> "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).
>>
>
https://bitbucket.org/openid/fapi/issues/343/what-is-authenticity-and-integrity-of-the



>
>>
>> "... 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
>>
>
https://bitbucket.org/openid/fapi/issues/344/x-isnt-cool-anymore



>
>>
>> "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.
>>
>
https://bitbucket.org/openid/fapi/issues/345/its-okay-if-a-refresh-token-can-be-guessed



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

-- 
_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/08142398/attachment-0001.html>


More information about the Openid-specs-fapi mailing list