Maintenance Iteration 19 Holistic Feedback

[CDR-API-Stream]

This change request has been created to simplify the raising of minor changes, such as text corrections or description clarifications, that are not really material to the standards but do have a real impact on readability and clarity.

Please raise any such suggestions that you would like included in Maintenance Iteration 19 on this issue and the DSB will review them. If a suggestion is a material change a dedicated CR will be raised.

[perlboy]

https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/561

[benkolera]

As discussed in the Implementation call 2024-05-30, I asked the question clarifying two parts of the current infosec standards around JARM encryption for recipients that appear to be in some conflict.

Data Recipient Software Products

Data Recipients MUST support [JARM] in accordance with [FAPI-1.0-Advanced] section 5.2.3.2.

In addition,

Data Recipients MUST request authorisation response signing using one of the authorization_signing_alg_values_supported values offered by the Data Holder.
Data Recipients MAY request response encryption using one of the advertised encryption sets.
Data Recipients MAY request no response encryption by omitting the values in their client registration.
If authorization_signed_response_alg is omitted, the default algorithm is "PS256".
Additional requirements and guidelines for the authentication flows are contained in the Consumer Experience section. 

and

JARM Response Encryption Considerations

If Data Holders support authorisation response encryption, they MUST support, at a minimum, one of each of the following alg and enc algorithms:

Claim   Values
authorization_encryption_alg_values_supported   RSA-OAEP, RSA-OAEP-256
authorization_encryption_enc_values_supported   A256GCM, A128CBC-HS256

Data Recipients MUST support the minimum required algorithms.

I know when we were discussing JARM standardisation we tried to make it as optional as possible, but personally could not remember whether there were any cases where ADRs were forced to support it even if they didn't want JWE. GIven that DCRs are requests only, there might have been legitimate cases where some DH IdPs might ignore the request for no JARM JWE and enable it anyway.

@markverstege in the call said the intent of this was actually only that an ADR only needs to support the minimum algorithms only if they are requesting encryption and that an ADR that does not request encryption does not need to support all of the encryption algorithms.

It's probably worth bringing up in the final MI call to just run it by folk that might remember something that Mark and I do not, but otherwise clarifying that final point to:

If requesting JARM response encryption, Data Recipients MUST support the minimum required algorithms.

would be awesome. :) I am a bit suspicious that there is context I am missing, though, given it doesn't really make sense to force full support of the minimum set either given it's optional and the ADR can always fall back to non JWE anyway if they don't support the enc alg of the holder. Like JARM JWE is either optional (and the ADR can choose an alg supported by the holder and not banned by fapi), or it's not, and even with the clarification the statement feels a little weird.

Edit after reading more standards

Sorry, I found in the standards the bit I was thinking about. The section above in the DH section for JARM says:

If the Data Holder supports authorisation response encryption and the authorization_encrypted_response_alg is 
omitted from the registration request, the Data Holder MAY require response encryption by returning a client 
registration response with the chosen “authorization_encrypted_response_alg” value.

So this means that the ADRs do actually have support all enc algs "just in case". If my memory serves, it was because some holders had already implemented JARM that always forced on JWE and we had to cater for those cases in the standards. Later on, this seems like a very expensive thing for ADRs to have to support (especially for new entrants to the ecosystem) for an edge case where we're not sure of how many holders there are that actually still need lean on this extra clause and need to force JARM JWE.

After all of this rambling, is this worth an actual MI ticket to consider deprecating JARM JWE for good now the dust on fapi 1 uplift has passed?

[CDR-API-Stream]

Thanks @benkolera, it would be great if you could create an issue on the standards-maintenance repository to address this.