[Openid-specs-fapi] FAPI 2.0

Torsten Lodderstedt torsten at lodderstedt.net
Thu Feb 27 14:50:48 UTC 2020


Thanks for the clarification. I would have thought this obligation is quite obvious. Well, life seems to prove the opposite :-)

> On 27. Feb 2020, at 14:36, Ralph Bragg <ralph.bragg at raidiam.com> wrote:
> 
> 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> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200227/1e50a9f0/attachment.p7s>


More information about the Openid-specs-fapi mailing list