[Openid-specs-fapi] FAPI 2.0

[Daniel Fett]

Good point!

What about this?

AS...

" * MUST provide a means for resource servers to verify the validity,
integrity, expiration and revocation status of access tokens, either by
providing an introspection endpoint [@!RFC7662], by exposing signature
verification keys, or by deployment-specific means."

Regarding Joseph's point of short-lived, unrevocable ATs, I propose to
add a note:

"Note: In deployments using exclusively short-lived access tokens that
cannot be revoked, RS and AS do not need to use or provide means for
checking the revocation status."

What do you think?

-Daniel


Am 27.02.20 um 14:09 schrieb Ralph Bragg:
>
> 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
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200227/6eb50a1f/attachment-0001.html>