[Openid-specs-fapi] FAPI 2.0

Daniel Fett fett at danielfett.de
Thu Feb 27 15:01:32 UTC 2020


I'm fine with adding private_key_jwt back into Baseline. It seems that
there are good reasons to do so. Security-wise, the difference to MTLS
is negligible.

I will do so in the next commit.

-Daniel

Am 27.02.20 um 15:22 schrieb Ralph Bragg:
>
> As a follow up there are some implementations which are making use of
> the jwt authorization grant that currently use client_id within the
> grant to perform client authentication. I’ve seen this used as and it
> is being proposed as a means of getting around the 90 day re-auth
> where a TPP can attest in a way that can be validated that it has
> obtained ongoing re-authorization from its customer without the
> customer being present.
>
>  
>
> https://tools.ietf.org/html/rfc7523#section-2.1
>
> The tokens are still sender constrained to tls but the authentication
> mechanism is performed by signing it also protects the “scope”
> parameter as this can be included inside the JWT. To reiterate, I’m
> fully onboard with sender constrains but I have concerns about push
> back and subsequent adoption if we force everyone to support
> tls_client_auth… especially as tls_client_auth is explicitly excluded
> by the Australian CDR.
> https://consumerdatastandardsaustralia.github.io/standards/#end-points
>
>  
>
> *From: *Ralph Bragg <ralph.bragg at raidiam.com>
> *Date: *Thursday, 27 February 2020 at 13:50
> *To: *Torsten Lodderstedt <torsten at lodderstedt.net>, Financial API
> Working Group List <openid-specs-fapi at lists.openid.net>
> *Cc: *Daniel Fett <fett at danielfett.de>
> *Subject: *Re: [Openid-specs-fapi] FAPI 2.0
>
>  
>
> Hi,
>
>  
>
> ·  MUST support client authentication and sender-constraining of
> access tokens using Mutual TLS as described in [@!RFC8705]
>
>  
>
> From a security point of view, MTLS is an edge device capability,
> private_key_jwt is preferred by many security folks, myself included
> that are worried about request alteration from within network segments
> that are behind the edge MATLS gateway. I also have concerns about
> this – immediately Australian CDR would be not FAPI compliant in anyway.
>
>  
>
> Sender constrained using MTLS but that can be done without mandating
> client authentication as well.
>
>  
>
> Be interested in others thoughts.
>
>  
>
> Kind Regards,
>
> Ralph
>
>  
>
> *From: *Ralph Bragg <ralph.bragg at raidiam.com>
> *Date: *Thursday, 27 February 2020 at 13:36
> *To: *Torsten Lodderstedt <torsten at lodderstedt.net>, Financial API
> Working Group List <openid-specs-fapi at lists.openid.net>
> *Cc: *Daniel Fett <fett at danielfett.de>
> *Subject: *Re: [Openid-specs-fapi] FAPI 2.0
>
>  
>
> Nope – just the fact that if an RS must do something then then an AS
> must provide a means of doing it and potentially describing how.
> Introspection? Shared keys for AT decryption? Either works.
>
> We were pretty good in the OB security profile to make sure both
> sides, where mutuality of obligation is required was detailed in the
> requirements.
>
>  
>
> *From: *Torsten Lodderstedt <torsten at lodderstedt.net>
> *Date: *Thursday, 27 February 2020 at 13:30
> *To: *Financial API Working Group List
> <openid-specs-fapi at lists.openid.net>
> *Cc: *Daniel Fett <fett at danielfett.de>, Ralph Bragg
> <ralph.bragg at raidiam.com>
> *Subject: *Re: [Openid-specs-fapi] FAPI 2.0
>
>  
>
> Are you referring to validity beyond „exp“, i.e. checking for revocation?
>
>
>
>
>
>     Am 27.02.2020 um 14:09 schrieb Ralph Bragg via Openid-specs-fapi
>     <openid-specs-fapi at lists.openid.net>:
>
>     Small one from me Daniel
>
>     *Requirements for Authorization Servers*
>
>     Doesn’t include explicitly the requirement to support a means of
>     validating that an access token is still valid. I had to add this
>     to the Open Banking security profile to force banks to either
>     share the keys with their RS’s or expose an introspection
>     endpoint. I know it’s stupid but can we please make sure that if
>     there is an explicit requirement to validate an access token on
>     the RS then there is an explicit obligation to provide a means to
>     do so on the AS.
>
>      
>
>     *From: *Openid-specs-fapi
>     <openid-specs-fapi-bounces at lists.openid.net> on behalf of Joseph
>     Heenan via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
>     *Reply to: *Financial API Working Group List
>     <openid-specs-fapi at lists.openid.net>
>     *Date: *Thursday, 27 February 2020 at 10:37
>     *To: *Daniel Fett <fett at danielfett.de>
>     *Cc: *Joseph Heenan <joseph at authlete.com>, Openid-specs-fapi
>     <openid-specs-fapi at lists.openid.net>
>     *Subject: *Re: [Openid-specs-fapi] FAPI 2.0
>
>      
>
>     Thanks Daniel - a few responses inline:
>
>      
>
>     (Any points I removed I agree with your response - thanks!)
>
>
>
>
>
>
>         On 27 Feb 2020, at 08:12, Daniel Fett <fett at danielfett.de
>         <mailto:fett at danielfett.de>> wrote:
>
>          
>
>         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.)
>
>     Good answer :-) I think it’s also a reasonable position given I
>     believe we’re not aware of deployments of FAPI-R.
>
>      
>
>              
>
>             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.
>
>     Good point.
>
>      
>
>     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).
>
>
>
>
>
>
>              
>
>             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.
>
>     Interesting, I never noticed that before. We may want to make the
>     language a little clearer in both places I guess.
>
>      
>
>     Joseph
>
>      
>
>     _______________________________________________
>     Openid-specs-fapi mailing list
>     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/cc160cee/attachment-0001.html>


More information about the Openid-specs-fapi mailing list