-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change id token encryption documentation to allow for use in Hybrid flow and ACF #576
Comments
As discussed in last week’s maintenance iteration call, dynamic client registration doesn’t support clients registering multiple software profiles with the same data holder. As such, oAuth clients are registered with the composite set of metadata provided in the registration request. This has caused problems for some data holders that cannot conditionally apply negotiated settings for different authorisation flows. With ID token encryption, this has meant that some data holders will continue to encrypt ID tokens at the Token endpoint for the Authorization Code Flow. This is currently in conflict with the standards that state that ID token encryption must not be performed for Authorization Code Flow (in other words, it was originally intended for OIDC Hybrid Flow only). To facilitate the transitionary period where OIDC Hybrid Flow is still supported, the following change is proposed: Security Profile -> Tokens -> ID Token -> Authorization Code Flow requirements:
Further considerations:
|
Thanks for the update - we appreciate the progress made on this topic. We would like to clarify however - will ADRs who have registered for both Hybrid and ACF have to update their registration with Data Holders on July 10th 2023? Since otherwise we still anticipate there would be a issue as the metadata would still drive some implementations to apply ID token encryption. |
We also note that within the DCR OpenAPI Specification these fields are listed as required: Will this be updated to reflect the recent changes? |
The expectation is that ADRs will transition to using ACF during the phase in period. The phase in period gives the ADRs time to fallback to Hybrid flow if they encounter issues. After 10th July it is then at the discretion of the DH when they retire the Hybrid flow so any DHs dropping support for Hybrid flow would no longer support it. ADRs would be expected to update their client registration accordingly to use only the ACF flow. The proposal above is that post-July 10th if a DH supports Hybrid flow and ACF, they no longer apply ID token encryption on the ACF flow. |
Yes. This should be set to conditional based on the DH supporting Hybrid flow. If they do not then it is optional for the ADR but also noting that if the DH no longer advertised ID token encryption support on the ACF flow then the value presented by the ADR will be ignored. |
As per the maintenance call today, we are supportive of this change being treated as urgent. |
The Data Standard's Chair has approved this issue be treated as urgent. |
There hasn't been any further feedback to this CR. As proposed, Data Holders supporting both OIDC Hybrid Flow and ACF can conditionally apply ID token encryption to the OIDC Hybrid Flow but not ACF after July 10. An alternative is to retain the "SHOULD NOT" statement whilst Data Holders support both OIDC Hybrid Flow and ACF. In this situation it is not incumbent on the Data Holder to change their implementation post-July 10 where both flows are supported. As Data Holders retire the OIDC Hybrid Flow, ID token encryption is dropped because they only support ACF. Under this option ADRs may continue to obtain encrypted ID tokens where the Data Holder advertises ID token encryption is supported and the Data Holder supports both OIDC Hybrid Flow and ACF. If the ADR is only registered for ACF then no encryption would be applied. It is only where the ADR has a client registration for both flows. |
ANZ is supportive of the alternative outlined above - allowing ID token encryption to be applied where both flows are still supported and registered with the Data Holder. We view this approach as beneficial from a transition perspective for ADRs and DHs. |
NAB is concerned that the proposal to force ID token encryption based on whether Hybrid flow or Authorization Code Flow is used is not aligned with OIDC standard and will break OIDC compliant implementations. This proposal is also not aligned with the desire to move away from CDR specific rules to full support of the industry standards. Similar concern about this proposal has already been raised by ANZ and we are supportive of their comments. Whether the ID token is encrypted or not should only be determined based on the “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata attributes, and there is no real harm in encrypting the ID token even when Authorization Code Flow is used, given that the ID token encryption is currently supported by both ADRs and DHs. If the intent of this proposal is to support both Hybrid Flow and Authorization Code Flow in the interim period and to ensure that ID token is encrypted when Hybrid Flow is used, then there is a much easier and standard compliant approach that can be taken, as follows: allow ID token encryption for Authorization Code Flow during the transition period and once we are ready to retire Hybrid Flow we can make the “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata optional and drop the support for Hybrid Flow. This will allow ADRs to decide whether they want to continue to receive ID tokens encrypted or not. Those ADRs who want to drop the support for ID token encryption can update their client metadata registration to remove “id_token_encrypted_response_alg” and “id_token_encrypted_response_enc” client metadata values. |
Hi @NationalAustraliaBank, that aligns with the alternative option proposed. The Based on the proposal above, the DCR swagger would be updated to denote that the fields are conditional based on the Currently:
Proposed:
The upstream OpenID.Registration specification describes the default where no encryption algorithm claims are provided is to not perform ID token encryption.
Regarding obligation dates, this simplifies the phasing without the need for the transitionary SHOULD NOT and MUST NOT statements. In effect, the proposal would be a simplification of the "Security Profile -> Tokens -> ID Token -> Authorization Code Flow requirements" section such that statements regarding encryption are removed allowing clients to update to ACF and omit the Current:
Proposed:
|
This change request was incorporated through decision proposal 298 |
Description
Decision Proposal 282 (ConsumerDataStandardsAustralia/standards#282) introduced changes to the DCR metadata fields "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc", which states: Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow.
This aspect of the standards is problematic for us – as our implementation will take the id_token encryption metadata and apply this regardless of whether Hybrid or ACF is used.
We suspect other Data Holders will have similar issues as this is how the product we use is designed and is aligned to the underlying standards - https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata, which don’t distinguish on the flow in which the token is issued:
id_token_encrypted_response_alg
OPTIONAL. JWE alg algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If this is requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. The default, if omitted, is that no encryption is performed.
id_token_encrypted_response_enc
OPTIONAL. JWE enc algorithm [JWA] REQUIRED for encrypting the ID Token issued to this Client. If id_token_encrypted_response_alg is specified, the default for this value is A128CBC-HS256. When id_token_encrypted_response_enc is included, id_token_encrypted_response_alg MUST also be provided.
Area Affected
https://consumerdatastandardsaustralia.github.io/standards/#client-registration - Registration Request using JWT
Change Proposed
Change the description of "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc” to remove the statement: “Required if OIDC Hybrid Flow (response_type “code id_token”) is registered. Must be ignored for Authorization Code Flow.”
DSB Proposed Solution
The current DSB proposal for this issue is in this comment
The text was updated successfully, but these errors were encountered: