Client Registration JWT needs to be updated for FAPI 1.0 Phase 3 client registration that uses Authorization Code Flow with JARM encryption

[AG-IAM]

Description

The Client Registration JWT payload shows "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" as required, however, the example Request for FAPI 1.0 Phase 3 client registration that uses Authorization Code Flow with JARM encryption does not show have those claims.

Area Affected

https://consumerdatastandardsaustralia.github.io/standards/?examples#client-registration > Registration Request using JWT

The example shows only "id_token_signed_response_alg"

Change Proposed

Option1: Mark the "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc" field of the Client Registration JWT as "Optional". If the values are NOT provided by ADR during client registration, then DH does not encrypt the id_token.

Option2: Update the example client registration JWT to include "id_token_encrypted_response_alg" and "id_token_encrypted_response_enc".

[CDR-API-Stream]

Hi @AG-IAM, #576 proposes this will be updated along the lines of Option 1 you present. The fields will be marked as Conditional to account for them being required if the client is registering for OIDC Hybrid Flow. The non-normative example would be aligned to this change because it is an example for registering a client to only use the Authorization Code Flow.

[nils-work]

Hi @AG-IAM

As per the statements in the previous comment -

576 proposes this will be updated along the lines of Option 1 you present.

and -

The non-normative example would be aligned to this change because it is an example for registering a client to only use the Authorization Code Flow.

and noting that #576 is now completed, do you consider that this issue can also be closed? (i.e. the id_token_encrypted_response_alg and id_token_encrypted_response_enc fields do not need to be added to the Authorization Code Flow example.)

[AG-IAM]

Hi @nils-work

Yes, this can be closed now. Thanks.