Question: Do JWS Signing Requirements only apply to Resource Server resources? Answer: Yes.

[dcreado]

Hi

the Message Content Signing Considerations of open-banking-brasil-financial-api-1_ID2 requires that iss and aud claims on JWTs requests and responses (I'm assuming here that id token is included as well) to be the organizationID for the issuer and client on the Central Bank Directory.

There are multiple specification that require and recommend those claims to be the issuer URL and client id, in order to implement an effective security on the client and server level without requiring a central authority. One aspect of the central authority is that it makes harder for implementing and debugging scenarios.

Here some conflicts that I can enumerate:

The JARM specification (https://openid.net//specs/openid-financial-api-jarm.html) requires that response iss must be the issuer URL and the aud claim to be the CLIENT ID.

https://openid.net//specs/openid-financial-api-jarm.html - section 4.1 The JWT always contains the following data utilized to secure the transmission:

iss - the issuer URL of the authorization server that created the response
aud - the client_id of the client the response is intended for
exp - expiration of the JWT

The OpenID Connect Core strongly recommend that iss and aud of the a Request Objects to be the client id and the issuer URL respectively.

The JWT Secured Authorization Requests (or JAR) also recommend the same approach, using the client id and the issuer URL for the iss and aud claims.

The OIDC Discovery state that the issuer URL must be the same as the iss claim of the id token, such that clients can validate the JWT based on the JWK exposed by that issuer.

From OIDC Discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)

issuer REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

I guess the question is why are we centralizing the security of every JWT token on the Central Bank Directory?

[RalphBragg]

This specification pertains only to the JWT message signing specification for resource non repudiation. It does not change the requirements to OIDC.

This alternative you proposed was discussed with the security group and rejected in favour of what is currently specified. The purpose of the JWT is not security (FAPI Guarantees this) but non repudiation.

In the case of Brazil Open Banking, it is an organisation that is assuming responsibility for the 'signature' of the message, not an oauth client. i.e if it would be contested the court wants to know what legal entity signed it there's no interest in which app.

The Brazil Certificate Profiles for signing are not bound to a specific application or software. The Brasil ICP specification only issues a cert to an organisation NOT to a software record or client.

These two key items led to the drafted approach being adopted over the one you suggested.

The second requirement you asked 'why is the central trust anchor' being used is because of a Banco Central requirement that payments are only initiated by participants registered with Open Banking. When a participant (or their software) is revoked on the directory, all JWKS keysets that are used to validate signatures and immediately emptied. This ensures that participants will only be relying on members that are active in the ecosystem.

There is no obligation and no published SLA for ICP Certificate Authorities to revoke the credentials (certificates) issued to participants in a manner that would allow this objective to be achieved.

Finally, by using the organisationId and the organisation key set, all participants have a deterministic location to source the public keys for resource signing and response signing if they are active on the directory. e.g if a JWT is issued by organisationId 12345678 and that organisation is an active participant in open banking then the keys will always be in the keyset location https://keystore.directory.openbankingbrasil.org.br/12345678/application.jwks in contrast, the clientId are issued by each bank and therefore unique between each bank / tpp pair.

The JWKS key entries are audited and validated on an ongoing basis with a complete history for the entire ecosystem of when they were modified and more importantly when they were removed (because there's no SLA for ICP revocation).

[dcreado]

Thanks Ralph,

indeed, there is no conflict with the OpenId Connect Core. But there is a conflict with JARM. https://openid.net//specs/openid-financial-api-jarm.html - section 4.1 The JWT always contains the following data utilized to secure the transmission: iss - the issuer URL of the authorization server that created the response aud - the client_id of the client the response is intended for exp - expiration of the JWT

I'm not sure how this will be addressed on the RP certification.

If the JWKS are hosted and managed by the directory, that is another aspect of the design. It is not required for hosting the certificates on the directory to change the iss and audience on the Request Objects and Response Objects to match the identifiers there. For instance: you might have a client id ABCD with its software statement and JWKS endpoint pointing to https://keystore.directory.openbankingbrasil.org.br/12345678/application.jwks.

I'm afraid that the specification is not matching what is implemented on the products available on the market, and that is not required to be done to implement non repudiation or promptly removing agents from the openbanking ecosystem.

[RalphBragg]

Hi,

Again, there is no issue with JARM or any of the openid connect / oauth 2 requirements. JARM is not affected at all. JARM is designed to protect the Authorization code exchange flow where the tpp is talking to the Authorization server, the payload signing specification is used to provide non repudiation when the tpp is communicating with a resource server. Very different purposes.

The openid foundation and Raidiam are already testing the brazil signing flavour implementation of this in the oidf conformance suite.

Given that two contributing authors to JARM are also building the conformance suites (plural) for Brazil it would be useful if you could share the clauses that are in conflict.

the resource signing spec does not in anyway change or impact any of the JARM or other TPP to AS communications. This signing spec is entirely focused on non repudiation for TPP to RS messages.

We (the foundation) will be sharing access to the beta for phase 3 testing very shortly.

[dcreado]

I think I got it now... The JWS section does not applies to request and response objects of the FAPI authorization endpoints. Is that correct? if that is the case, the text needs to be clearer on where does that applies to or suppress the section from ID2 as it implies that every JWT requests and responses (including the authorization) are affected.

[RalphBragg]

hi - this is correct and yes on second reading it isn't clear. I have a draft pull request to tidy up ID2 from an english language view point. A section for resource server requirements need to be created where this will be refrenced.

[dcreado]

ok! now it makes complete sense :)

[dcreado]

thank you!