Hello. We've been trying to use keycloak to protect API services provided by financial institutions. Under governmental regulation (e.g. Payment Service Directive(PSD2) in Europe), high level security is required for financial sector. One of the most promising security standard for financial API services is Financial API(FAPI) of OpenID Foundation. This is still implementer’s draft, but banking API systems compliant to FAPI are being implemented in some countries. We've investigated keycloak and found that keycloak does not meet some of FAPI Security Profile requirements. We've been engaging in realizing them in keycloak, but had a lot of works. Is there someone who is interested in it? Also, I'm afraid that someone has already planned to support FAPI requirements and/or done some of them. Because it seems that there are some related JIRAs, please tell us the plan of related JIRAs(below 1) tickets). We’ve created JIRA tickets to realize FAPI. Some tickets have already been resolved while others have been newly created. Also advice of how to proceed is also welcomed. 1) Aggregated tickets https://issues.jboss.org/browse/KEYCLOAK-6767 2) Related to existing tickets * signed and encrypted ID Token https://issues.jboss.org/browse/KEYCLOAK-6768 It seems that JWE has already been implemented and adopted to authorization code. Is there any plan to realize signed and encrypted ID Token using this JWE libraries? https://issues.jboss.org/browse/KEYCLOAK-5288 https://issues.jboss.org/browse/KEYCLOAK-5290 https://issues.jboss.org/browse/KEYCLOAK-5569 * Multi-factor authentication and its corresponding "acr" value in ID Token https://issues.jboss.org/browse/KEYCLOAK-6769 There has already been some discussion on this issue, but not resolved. Is there any plan to continue and resolve it? https://issues.jboss.org/browse/KEYCLOAK-3314 2) Newly created * JWS signatures using PS256 or ES256 algorithms for signing https://issues.jboss.org/browse/KEYCLOAK-6770 We’ve investigate why FAPI excludes RS256 and found that RS256 (RSASSA-PKCSv1.5) seems to be considered not secure because several vulnerabilities have been reported. There are a lot of points using JWS signature not only Access/Refresh/ID Token but Requesting Party Token, Permission Ticket, Request Object, Response from UserInfo Endpoint, JWS Client Assertion, JWT telling events to Clients using client adapter. But I think only it be adequate to target Access/Refresh/ID Token at this time. However, I’m afraid that some of these points use hard-coded RS256 JWS signature so that it might be difficult to choose other signature algorithm like ES256. As for signature algorithm, it might be easier to adapt PS256 than ES256 because PS256 is RSA based signature algorithm (RSASSA) like RS256 so that key pair representation is the same. Therefore, I think PS256 could share the same RSA key pair as RS256. However, it seems that OpenJDK does not support PS256 (“SHA256withRSAandMGF1”). Considering this point, ES256 (“SHA256withECDSA”) might be only viable option, but additional works like key management be needed comparing with PS256. * Holder of Key mechanism: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens https://issues.jboss.org/browse/KEYCLOAK-6771 keycloak has already implemented treating X.509 Client Certificate in TLS session. Also, keycloak has implemented JWS Client Assertion in private so that it has capability of managing X.509 Client Certificate. It seems that these feature can be used to calculate X.509 Client Certificate thumbprint and embed it onto Access Token that can be used in Sender Constraint. * State hash value (s_hash) to protect state parameter https://issues.jboss.org/browse/KEYCLOAK-6700 PR was sent. 3) Resolved * RFC 7636: Proof Key for Code Exchange by OAuth Public Clients https://issues.jboss.org/browse/KEYCLOAK-2604 * scope returned in the response from Token Endpoint https://issues.jboss.org/browse/KEYCLOAK-5661 * OIDC Client Authentication by JWS Client Assertion in client_secret_jwt https://issues.jboss.org/browse/KEYCLOAK-5811 Best Regards Takashi Norimatsu Hitachi, Ltd.