da-banking
commented
3 years ago From the part 1 review:
5.2.3 (10) token response scope value shall verify that the scope received in the token response is either an exact match, or contains a subset of the scope sent in the authorization request
This is part of a sublist which is clarified with “If openid is not in the scope value, then the public client”, and appears to be referring to the requested scope – since open banking requires openid anyway, this change does not apply.
Note: Although this now requires clients to explicitly validate the scopes returned 5.2.2 (15) essentially overrides this from the perspective that the CDR uses token responses in the back channel that integrity protected. In this situation, ADR clients would not receive a list of scopes and this leaves consent in a somewhat ambigous state. There is also clearly an onus on the DH to only grant the client the scopes that it supports and not additional scopes it doesn't support. With the phasing of obligations in the ecosystem creates something of an undefined behaviour.
The ambiguity only exists if ADRs are not limiting the scopes they request to what is listed in the data holder’s discovery document when constructing the authorisation request. For what reason is scopes_supported mandatory to implement if not for an ADR to know exactly what scopes a DH is currently supporting?
From the part 2 review:
PKCE offers some significant advantages vs hybrid flow most notably simplifying the client implementation
I do not understand this statement. As far as I understand it, PKCE is added on top of the request and does not remove requirements on validating the response at the client. i.e. there will still be hybrid flow, just with PKCE being mandatory instead of optional. Is this meant to be about the proposal to use JARM instead of hybrid flow later in the analysis?
NOTE: there is a current issue with loss of authorisation code in exchange for tokens causing real production issues in the CDR. Could the introduction of PKCE and the code verifier method alleviate this? Because the code_challenge_method is bound to the authorisation code can the authorization_code be re-usable where it has not been successfully exchanged. Within a window - say 60 seconds or 5 minutes, the authorisation code can be replayed with the code verifier (as proof the client requesting tokens is the client that initiated the request) and the authorization_code is expired upon an authorization_code lifetime. If the authorization_code is replayed the AuthZ Server would issue the same tokens it did (or thought it had) issued the first time.
This would go against the requirement to reject an authorization_code if it has already been used and could potentially open the server to security holes. A malicious party that somehow obtains a verifier (such as a lookup via a rainbow table on the hashed value) can wait until nearing the end of such a time limit and then “redo” the exchange – it looks fine to the data holder, and the original ADR may not become aware of it until much later (if at all).
8.9 (3) does not allow the same kid to be used by multiple keys within a JWKS
8.9 (3) is a recommendation that the kid is not reused, not a requirement. I am not against it being a requirement for open banking – just that it’s not mandatory by FAPI 1.0 Advanced
From the PAR review:
Should the CDS explicitly define the request_uri must only be used once and cannot be replayed? Should the CDS explicitly define the upper lifetime of the request_uri?
Yes
Determine the appropriate HTTP status code and oAuth error code to respond with when the request_uri is re-used. Currently presumed this is a 400 (Bad Request) and oAuth error invalid_request or access_denied.
It should be invalid_request_uri, originally defined by OIDC – assuming that enough of the request_uri exists to identify the redirect_uri. Some implementations may have deleted request_uri data immediately after use, so may not be able to redirect back and would instead have to display an error page.
Introduces the new OIDD metadata parameter require_pushed_authorization_requests. Recommended that DHs can choose whether to require this and if so ADRs MUST only use PAR if true. This would give DHs more discretion over security and simplification of implementation. The CDS doesn't need to override or preclude this. If there is a desire to simplify the CDS, it may be preferred to limit the CDS to always require PAR for better interoperability in a many-to-many ecosystem and reduce interoperability choices.
PAR is already required for amendments, and ADRs may need to support it anyway if a DH uses require_pushed_authorization_requests=true It seems simpler to just mandate PAR for all requests.
2.2.: Drops mention that the request_uri is intended for one time use. There is currently no clause in FAPI 1.0 that restricts this meaning that Authorisation Servers MAY implement the request_uri in such a way that it can be re-used within its lifetime or be recycled. This is still cryptographically bound to the oAuth client however there may be issues where it could be replayed within a short period of time. Old clause Since the request URI can be replayed, its lifetime SHOULD be short and preferably limited to one-time use. NOTE: Should the CDS prevent this, or is this replay not seen as an issue - it may be useful where the client attempts to go through the authorisation flow but encounters a technical issue and can replay the request_uri without re-staging it though this seems to be of little benefit. It is pre-authentication so again, there is limited opportunity for malicious use/replay attack. The only question is whether a simplified authentication flow may be impacted if the consumer is not required to authenticate.
FAPI requires the use of PKCE for PAR requests. Allowing PAR reuse could potentially allow a situation where two requests are being handled at the token endpoint during authorization_code exchange, the verifier for the second would effectively be known in advance. Potential security hole.
7.5 Request URI Swapping
Clients SHOULD make use of PKCE [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" parameter [OIDC] in the pushed request object to prevent this attack. Hybrid flow already requires the use of a nonce, so this is already covered. The addition of FAPI 1.0 requiring PKCE does not alter existing implementations WRT to mitigating this (but doesn't hurt either)
CDR-API-Stream
AusBanking
PratibhaOrigin
EnergyAustraliaBA
perlboy
da-ay
anzbankau
cloudentity-io
biza-io
WestpacOpenBanking
December 16 2021: Decision Made This decision was approved by the Data Standards Chair on 16 December 2021. The decision record is attached below: Decision 209 - Transition to FAPI 1.0 Advanced Profile.pdf
10th November 2021: Decision Proposal 209 Feedback Consultation Date: The feedback consultation date has been extended to the 19th of November 2021.
18th October 2021: Decision Proposal 209 Published:
This decision proposal outlines a a proposal for the transition of the CDR Information Security profile to adopt FAPI 1.0: Baseline and Advanced (Final) profiles as well as RFC9126 (Pushed Authorization Requests).
The decision proposal is attached below: Decision Proposal 209 - Transition to FAPI 1.0 Advanced Profile.pdf
This consultation will be open for feedback until the 19th November 2021
16th November 2021.2nd September 2021 placeholder requesting early feedback was published: Placeholder for a decision proposal outlining the transition of the CDR Information Security profile from Financial-Grade API (FAPI) Implementer's Draft v06 (ID2 Draft 06) to FAPI 1.0 Final. Further details are available in Future Plan Item 46.
A decision proposal will be posted here once developed. In the meantime any feedback suggestions for inclusion in the decision proposal are welcome.
Some initial feedback has been received in submissions to Decision Proposal 182 and Normative Standards Review 203. A preliminary gap analysis has also been conducted: