Question: Encrypted JWE requirements, where are the keys?

[DeiGratia33]

Since the usage of JWE is supported by the specification, we need to make clear at the specification the keys used for Encryption, as the JWKS used to store the keys.

Authorization Server and Client App.

[RalphBragg]

Hi,

The JWKS contains an entry for ENC as defined in the JWKS endpoint. https://datatracker.ietf.org/doc/html/rfc7517

4.2. "use" (Public Key Use) Parameter

The "use" (public key use) parameter identifies the intended use of the public key. The "use" parameter is employed to indicate whether a public key is used for encrypting data or verifying the signature on data.

Values defined by this specification are:

o "sig" (signature) o "enc" (encryption)

Other values MAY be used. The "use" value is a case-sensitive string. Use of the "use" member is OPTIONAL, unless the application requires its presence.

When a key is used to wrap another key and a public key use designation for the first key is desired, the "enc" (encryption) key use value is used, since key wrapping is a kind of encryption. The "enc" value is also to be used for public keys used for key agreement operations.

[perlboy]

It seems relevant to highlight at this point that the FAPI Conformance suite assumes the JWE (if present) is the first entry in the JWKS. Also, some implementations barf if use is missing.

[RalphBragg]

@perlboy Wrong endpoint / usage mate. The requirement is to support encrypted request objects which are encrypted with the Banks Private Key from the Banks JWKS. The issue you're talking about is where you are testing encrypted ID Tokens which isn't required for Brazil which requires the 'enc' key to be the second entry in a JWKS you supply to the fapi conformance harness

Joseph can confirm but it's not an issue for Brazils security profile.

[esachser]

The key registration in the JWKS is made clear by the standards. But these questions remain for Open Banking Brasil:

1. Is the "enc" key associated with any certificate (ICP-Brasil or otherwise) or should the ASPSP just generate a key pair and publish it in the JWKS?
2. Are these JWKS going to be published in the Directory or should the ASPSP just host the file on their own domain?
3. If the ID token is to be encrypted (when they contain sensitive PII, reference below), should every TPP have a "enc" key on their JWKS? https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html#section-5.2.2.1-3.1.1

[RalphBragg]

3. There is no requirement currently expressed for encrypted id_tokens in the 'front channel'. If you have a need to be doing this can you please raise this with the security working group. id_tokens with consumer claims should only be necessary via the token endpoint, and again only if a Bank chooses to include them in the token instead of providing them via the user info endpoint.

The token endpoint is already appropriately secured and thus do not need to be encrypted. Making TPPs deal with encrypted id tokens because a bank can't properly implement the hybrid flow wouldn't be ideal.

There is no requirement for TPPs to support encrypted id_tokens in the security profile as there is no reason for Banks to put PII in the front channel id_token for Brazil, therefor there is no current justification (or clause in the security profile) for Banks to enforce their use.

Using encrypted id_tokens via the backchannel would prevent their use as a CIBA identity hint which is currently being considered as a required supported mechanism for phase 3 payments.

For 1 and 2: Banks are currently allowed in the short term to host their own JWKS endpoints and advertise them on the well known. Support for the upload of an 'enc' key is supported in the directory and there has been no direction to use ICP certificates for this purpose so far.

@ginglass

[esachser]

For 1 and 2: This should be defined in the specs. It's important, because it involves aquiring or not new certificates. For 3: So, if some TPP requests cpf or cpnj claim on id_token as essential, is it possible for the AS to reject the authorization request by not supporting encrypted id_tokens? Reading https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID1.html#name-requesting-the-cpf-claim and specially:

If this is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat that outcome as a failed authentication attempt.

[jogu]

For 3: So, if some TPP requests cpf or cpnj claim on id_token as essential, is it possible for the AS to reject the authorization request by not supporting encrypted id_tokens?

Note that there are two id tokens returned to the relying party if using response_type=code id_token.

Privacy sensitive claims must not be returned (unencrypted) in the front channel id_token (i.e. the one returned from the authorization endpoint).

The most sensible approach is to return cpf / cpnj only in the id_token returned from the token endpoint. Using JARM is also a sensible option. If you can't take either approach, my understanding is you're required [by FAPI] to support encrypted id tokens, but as per Ralph's comment above it seems this option is problematic in Brazil.

Triggering a failed authentication when the authenticated user has the cpf value requested in an essential claim would not be sensible.

[RalphBragg]

Thank you Joseph - implementers still get confused with the id_token as a detached signature in the front channel vs an id_token in the backchannel it seems. Perhaps another workshop on OIDF FAPI fundamentals might be useful. I'll talk to Mike L

[TakahikoKawasaki]

[RalphBragg]

If there's no further feedback and given the number of successful passes of the security and functional tests i'm going to close this ticket as no longer being required. Feel free to re-open with a proposal for an improvement.