[Openid-specs-fapi] Questions / comments on FAPI 2.0 Baseline Profile
ralph.bragg at raidiam.com
Sun Mar 15 18:08:36 UTC 2020
On 1; Public client support is removed, the security issues are well documented with public clients however this does not mean native app clients are not supported. A native app, particularly on modern smart phones, can and should be implemented as private clients.
From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of "Peck, Michael A 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: Sunday, 15 March 2020 at 18:04
To: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Cc: "Peck, Michael A" <mpeck at mitre.org>
Subject: [Openid-specs-fapi] Questions / comments on FAPI 2.0 Baseline Profile
I have some questions and comments on the current draft of the FAPI 2.0 Baseline Profile (https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md).
I’m new here, please let me know if I’m misunderstanding something / if these are more appropriate for the issue tracker instead.
The profile appears to not allow public clients. Is that intentional? If so, why not – are native app clients not an intended use case?
(Requirements for Authorization Servers #9 states “MUST authenticate clients” and Requirements for Clients #4 states “MUST support client authentication”, which to me preclude public clients.)
The profile requires that resource servers verify the revocation status of access tokens (Requirements for Resource Servers #3). Is this practical?
Requirements for Authorization Servers #15 states “MUST provide a means for resource servers to verify the validity, integrity, sender-constraining, scope…expiration and revocation status of an access token, either by providing an introspection endpoint…by exposing signature verification keys, or by deployment-specific means.”
I would think the revocation status requirement would force the resource server to connect back to the authorization server (to its introspection endpoint or other “deployment-specific means”) every time an access token is presented, which might not always be feasible?
I don’t see how “exposing signature verification keys” would suffice to meet the revocation status verification requirement?
Another option might be to weaken the MUST for verifying revocation status of access tokens, add a requirement that the AS limit the lifetime of access tokens, and ensure that the AS check the revocation status of refresh tokens when they are presented? That would enable resource servers to more safely accept access tokens without having to reach back to the AS every time to check revocation status?
Requirements for Resource Servers #6 states “MUST identify the associated entity to the access token”.
What does “associated entity” mean? Does it mean the subject of the access token?
Cryptography and Secrets #3 states “authorization servers MUST provide a client secret that adheres to the requirements…if a symmetric key is used.”
I think this statement should be removed since the profile does not allow a symmetric key / client secret to be used for client authentication?
The MITRE Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi