Clarification on Minimum Algorithm Required for JARM

[spikejump]

Description

The latest spec has a section titled "ID Token Algorithm Selection Considerations", there is the explicit statement of "Participants MUST support, at a minimum, the following ID Token algorithms"... There is similar algorithm call out of PS256 and ES256 under the section "RegistrationProperties/Enumerated Values". The original idea way back was to specify some algorithms in the spec to minimise the ADRs needing to support a large number of algorithms simply to connect to the DHs.

Given the new requirement to support JARM, perhaps same consideration can be specified in the spec for minimum algorithm that DHs MUST support for JARM signing/encrypting?

Change Proposed

Similar to ID Token Algorithm, perhaps specify the minimum algorithm for

• JARM signing: PS256 (note that JARM spec defaults to RS256 as the algorithm); and
• JARM key encryption: RSA-OAEP/RSA-OAEP-256; and
• JARM payload encryption: A256GCM/A128CBC-HS256

DSB Proposed Solution

The current DSB proposal for this issue is in this comment.

[perlboy]

JARM uses JWS and therefore FAPI is already prescriptive on this.

As JARM is purely a non-repudiation method (which is the ID Token's real purpose in Hybrid flow) there is no reason to perform encryption of its responses nor does FAPI require it. Enabling encryption on JARM would be a repeat of the ID Token encryption decision (in my opinion a mistake) for literally zero benefit as JARM is incapable of transferring data claims beyond those necessary for non-repudiation (code & state).

[spikejump]

Does FAPI calls out minimum algorithms that must be supported by implementers? If so, do you mind reference it?

From an ADR's perspective, if a minimum set of algorithms are specified then ADRs will not be faced with the prospect of supporting all the possible algorithms.

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It was agreed to incorporate this change request into this maintenance iteration.

As per JARM section 5, Data Holders advertise signing and encryption algorithm support via their OIDD:

• authorization_signing_alg_values_supported -- JSON array containing a list of the JWS [RFC7515] signing algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to sign the response. The none algorithm, i.e. a plain JWT, is forbidden.
• authorization_encryption_alg_values_supported -- JSON array containing a list of the JWE [RFC7516] encryption algorithms (alg values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.
• authorization_encryption_enc_values_supported -- JSON array containing a list of the JWE [RFC7516] encryption algorithms (enc values) JWA [RFC7518] supported by the authorization endpoint to encrypt the response.

These are negotiated through dynamic client registration services.

Discussion considered two approaches:

• Option 1: Remain silent and defer to the upstream specifications.

  • This leaves algorithm choice to the Data Holder in line with the RFC7515 and RFC7516 provisions.
  • The onus is then on ADRs to support all recommended algorithms in RFC7515 and RFC7516

• Option 2: Define a mandatory minimum set of algorithm support

  • This is similar to ID Token Algorithm Selection Considerations
  • This defines a minimum set of supported algorithms that Data Holder MUST support.
  • Data Holders MAY support additional algorithms in line with the RFC7515 and RFC7516 provisions.
  • The onus is then on Data Holders to support a minimum algorithm set
  • Data Recipients can then reliably chose a single preferred algorithm based on their software stack knowing that all Data Holders support that minimum.
  • Data Recipients MAY support all recommended algorithms in RFC7515 and RFC7516

If Option 2 is preferred, agreement on the minimum set is sought.

Note that according to RFC7518 section 5.1, A128CBC-HS256 with content encryption algorithm AES_128_CBC_HMAC_SHA_256 and, A256CBC-HS512 with content encryption algorithm AES_256_CBC_HMAC_SHA_512 are REQUIRED content encryption algorithms.

According to RFC7518 section 3, HS256 is a required signing algorithm however PS256 is Optional. ES256 is strongly recommended and RS256 is recommended.

No key encryption algorithms are required according to RFC7518 section 4.1, but RSA-OAEP and ECDH-ES are strongly recommended.

[anzbankau]

We support Option 2 - explicitly defining a minimum set of algorithms (as has been done for ID token signing/encryption and request object signing) makes the most sense and avoids the introduction of weaker algorithms.

From recent discussions we note that it has been discussed that the JWT should not be encrypted - we agree with this position and would like it formalised into the specifications.

We also note that these items are necessary clarifications in order to enable FAPI 1 phase 3 implementations.

[spikejump]

Intuit supports Option 2 as it provides a fixed set of algorithms required to be supported by ADRs.

[CDR-API-Stream]

The current draft of the FAPI 2.0 Message Signing requirements (see Authorization Response Encryption) it includes a note that authorisation response encryption is not required. The DSB proposes a third option to this change request:

Option 3: Prohibit authorisation response encryption
Implementation requirements of JARM are to support message signing but not encryption. No Data Holder can implement JARM encryption and there is not need to specify authorization_encryption_alg_values_supported or authorization_encryption_enc_values_supported.

This option would constrain FAPI_2.0-JARM such that authorisation response encryption is not allowed.

This reduces ecosystem complexity and ADR implementation costs. If in future, FAPI 2.0 permits or requires authorisation response encryption, it would create a future breaking change for CDR implementations. Given the guidance by the FAPI working group draft on FAPI message signing is to not require authorisation response encryption, this risk seems low.

---

Note that Option 1 and 2 deal with the current requirements in the data standards. There is discretion for Data Holders whether they support support authorisation response encryption (it is not stated as mandatory in the Data Standards, only that Data Holders must implement JARM in accordance with the upstream specification). If they do, Option 1 vs Option 2 is still a design consideration.

Options 1 and Option 2 allow Data Holders to have discretion to require authorisation response encryption. This does mean that all ADRs must effectively handle encryption of authorisation responses even when some Data Holders do not support it.

[CDR-API-Stream]

If Option 2 is preferred to constrain signing algorithm support, the DSB proposes aligning to the current requirements for token, request object and ID token signing by constraining choice to PS256 and/or ES256.

Further discussion on encryption algorithm support will be discussed in the next Maintenance Iteration call (31/08/2022). Please note that Option 2 proposes a minimum set of algorithms be agreed to that Data Holders must offer (see "ID Token Algorithm Selection Considerations" for reference). Data Holders may support other encryption algorithms beyond that minimum set in accordance with upstream specifications.

[spikejump]

Regarding Option 3: Perhaps it is better for the standard not to override upstream standard? May be let DHs decide whether they want to support encryption or not. If so, publish using authorization_encryption_alg_values_supported and authorization_encryption_enc_values_supported. If both missing then DHs do not support encryption.

As an ADR, we'd rather deal with the complexity once as opposed to possibly do another uplift later and incurring another cost in resource/testing/time/etc. Moreover, JWT encryption is not new for the ecosystem.

[anzbankau]

In addition to our previous support of Option 2, we are also supportive of Option 3.

For both Options 2 and 3 we would like to see the algorithms for signing be explicit within the standards. We agree with the DSB that PS256 and ES256 are suitable.

[dpostnikov]

In regards to optional encryption with JARM and FAPI...

JARM specification can be used in different circumstances, with FAPI and without FAPI security profile.

In CDR case (as it stands at the moment), when used with FAPI security profile, with the payload we have in CDR ecosystem, encryption is not providing any additional security benefit. In fact, unnecessary encryption will cause more interoperability and security issues issues in addition to added complexity for data recipients.
This statement is aligned with OIDF FAPI WG view.

@spikejump, this is an example of a specification profiling (reduce the options available based on ecosystem requirements), which is perfectly sound unlike overriding or changing upstream specification.

So option 3 should fit everyone's requirements from encryption perspective.

[CDR-API-Stream]

This issue was discussed in the maintenance iteration 12 call.

Whilst there has been feedback to suggest prohibiting encryption for JARM responses would not have any security implications and would present a profiling of the FAPI 2.0 specification, there was no consensus to select Option 3.

The DSB proposes selecting Option 2 and defining a minimum set of signing and encryption algorithms. If there is further support to profile the FAPI 2.0 specification to prohibit encryption for JARM responses, this can be adopted at a later time. Option 2 presents a middle ground and the ADR feedback received has indicated that dealing with encrypted responses is workable.

Signing Algorithms
FAPI 2.0 is recommending support for EdDSA. Currently the Consumer Data Standards remain aligned to FAPI 1.0 and support PS256 and ES256. It is proposed that the minimum signing algorithmic support is defined to be PS256 and ES256. It is proposed that adoption of EdDSA be consulted as a separate change request because this will result in breaking changes to Data Recipients.

These would be advertised by Data Holders using the authorization_signing_alg_values_supported authorization server metadata parameter.

Encryption Algorithms

Encryption algorithm requirements are defined via authorization_encryption_alg_values_supported and authorization_encryption_enc_values_supported. It is proposed that the minimum algorithm selection align to the "ID Token Algorithm Selection Considerations" section of the data standards. Namely:

Claim	Values
id_token_encrypted_response_alg	RSA-OAEP RSA-OAEP-256
id_token_encrypted_response_enc	A256GCM A128CBC-HS256

Aligning JARM algorithmic support would be as follows:

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

[anzbankau]

As per the discussion in today's maintenance iteration call - we are stating our support for this issue to be treated as urgent.

[CDR-API-Stream]

The current proposed solution is to adopt the change as proposed here with an obligation date of April 7th 2023 for ADR and DH support.

[CDR-API-Stream]

The Data Standard's Chair has approved this issue be treated as urgent in combination with #547.

[ikawalec]

Encryption Algorithms

Encryption algorithm requirements are defined via authorization_encrypted_response_alg_values_supported and authorization_encrypted_response_enc_values_supported. It is proposed that the minimum algorithm selection align to the "ID Token Algorithm Selection Considerations" section of the data standards. Namely:

Could you please clarify this section.
Is authorization_encrypted_response_alg_values_supported and authorization_encrypted_response_enc_values_supported a typo, and it should be
authorization_encryption_alg_values_supported, authorization_encryption_enc_values_supported instead?

[CDR-API-Stream]

Hi @ikawalec, you are correct that was a typo. This has been corrected in the comment above.

[nils-work]

This change request was incorporated through ConsumerDataStandardsAustralia/standards#282 (comment)