Data Recipient Software Product unable to indicate optional idtoken encryption requirement

[renjith85]

Description

Phase 2 FAPI 1.0 Baseline and Advanced support proposal indicates that ID Token encryption must be changed from MUST to MAY - "ID Tokens MUST be signed and MAY be encrypted when returned to a Data Recipient Software Product from both the Authorisation End Point and Token End Point."

With the existing CDR DCR swagger definition, it is not possible to register an ADR using DCR to indicate that it does not require the idToken encrypted. Currently the CDR DCR swagger spec has the id_token_encrypted_response_alg & id_token_encrypted_response_enc fields as required which means there is no way for ADR/clients using DCR to indicate that they require non encrypted idTokens unless the CDR DCR swagger definition makes those field OPTIONAL.

Area Affected

Couple of object properties(id_token_encrypted_response_alg, id_token_encrypted_response_enc) in the ClientRegistrationRequest utilized in DCR (https://consumerdatastandardsaustralia.github.io/standards/#dcr-apis) APIs to be made optional

Change Proposed

To adhere with core OIDC DCR specification, if idToken encryption is optional, then the below fields should be made optional in the RegistrationProperties object used in the ClientRegistrationRequest for CDR DCR API

` 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. `

DSB Proposal

It is proposed this issue be closed as addressed in the comment below.

[perlboy]

If an ID Token isn't exchanged it will never be encrypted. At this stage I believe ID Token encryption is still required but a Recipient can elect to use code only flow (with PKCE) and avoid having to exchange ID Tokens at all.

[AG-IAM]

If an ID Token isn't exchanged it will never be encrypted. At this stage I believe ID Token encryption is still required but a Recipient can elect to use code only flow (with PKCE) and avoid having to exchange ID Tokens at all.

Isn't openid a mandatory scope, so the id_token will be returned from token endpoint.

[CDR-API-Stream]

With the changes proposed in #666, it is proposed that ID token encryption is removed because OIDC Hybrid Flow support will be formally retired. Authorization Code Flow will be the only supported flow which requires JARM and PKCE. As a result, ID Tokens will no longer be delivered via the front channel.

Therefore, it is proposed this issue be closed.