CIBA spec: id_token_hint is unspecified

[marcusalmgren]

According to recent discussions, the hint type applicable in the first iteration of OFBR FAPI-CIBA is the id_token_hint. This hint type is not mentioned in https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-CIBA-1_ID1.md, and the CIBA spec has the following to say under Security considerations:

An id_token_hint cannot be validated using standard JWT processing rules because the token is being used in a context (sent from the Client back to the OP) that is different than that for which it was originally issued (typically a short-lived token issued by the OP intended to convey claims about the authentication of an end-user to the Client). An expired ID Token therefore could still be considered valid as an id_token_hint so an OP should, for some reasonable period, accept id_token_hints with an expiration time that has passed. The OP should ensure that it is the issuer of the token and that the Client presenting the id_token_hint is listed in the audience claim. The OP should verify the signature to ensure that the token was, in fact, issued by it and hasn't been modified since. Note that due to key rotation, however, the OP may not necessarily have access to the key used to sign the token, so the length of time an ID Token is considered a valid hint will be likely to be limited by the OP's key rotation interval and retention period. Given these restrictions, implementers may consider not verifying the signature at all and only accepting ID Tokens with pairwise subject identifiers as hints. The OP could then validate that the Client authenticated at the Backchannel Authentication Endpoint was issued the pairwise subject identifier (or shares a Sector Identifier with the Client who was issued the pairwise subject identifier).

Given the above, it would seem reasonable that it is specified within OFBR:

• For how long after expiration should an OP consider the id_token sent in id_token_hint to be valid as a hint?
• What kind of validations are applicable on the id_token, given that the token is most likely expired?
• Should the signature be validated, and if so, how would that be impacted by possible key rotations?
• Assuming that the id_token is subject to some form of validation and expiration policy, should there be some guidance on how RPs should react to expired_login_hint_token responses?

[guilhermedecampo]

For how long after expiration should an OP consider the id_token sent in id_token_hint to be valid as a hint?

If the id_token has already expired, this means that it can no longer be trusted to properly identify the user who is trying to access a protected resource. Additionally, using expired tokens can increase security risks, as these tokens may have been compromised or could be falsified. Therefore, it is mandatory that the OP does not use the id_token after its expiration time and instead requests a new access token for the user.

What kind of validations are applicable on the id_token, given that the token is most likely expired?

Parameter	Validations
iss	- Authorization Server deve estabelecer identificador, ou conjunto de identificadores "iss" padrão para uso em transações CIBA.- Authorization Server não deve aceitar "iss" diferente de seu próprio identificador, ou conjunto de identificadores, padrão.
sub	- Authorization Server deve verificar se o identificador "sub" em questão já foi emitido para um cliente/conta, e se está válido dentro de seus requisitos.
aud	- Authorization Server não deve aceitar "aud" diferente do client_id de onde se origina a solicitação de autorização para o fluxo CIBA
exp	- "exp" deve ser estabelecido conforme políticas de risco da intituição Detentora de Conta.- Authorization Server não deve aceitar solicitações de autorização cuja data/hora é maior que "exp".
iat	- Sem validações específicas
auth_time	- Sem validações específicas
nonce	- Sem validações específicas para o AS
acr	- Se presente, o AS deverá aceitar apenas valores iguais ou acima dos requisitos de autenticação da Detentora para autorizar transações de pagamento.
amr	- Se presente, o AS deverá aceitar apenas valores iguais ou melhores que os requisitos de autenticação da Detentora para autorizar transações de pagamento.
azp	- Authorization Server não deve aceitar "azp" diferente do client_id de onde se origina a solicitação de autorização para o fluxo CIBA

Should the signature be validated, and if so, how would that be impacted by possible key rotations?

Signature should be validated on the account provider side. Just like the normal flows for rotations a new certificate should be added in the jwks list.

Assuming that the id_token is subject to some form of validation and expiration policy, should there be some guidance on how RPs should react to expired_login_hint_token responses?

Yes we should define the rules on how to deal with expired id_tokens and how we would create a hybrid flow again so we can collect the id_token for next CIBA flows. We’ll add this topic to UX guide and also implementation of documentation of CIBA.

[jogu]

I checked the id_token lifetimes for a random set of Brazilian banks, here are the results:

https://www.certification.openid.net/log-detail.html?log=CknlUP804u6h1MV&public=true : 60 minutes

https://www.certification.openid.net/log-detail.html?log=OlNF6dqLzTQScjb&public=true : 60 minutes

https://www.certification.openid.net/log-detail.html?log=i9w2vJOipvgwaKa&public=true : 60 minutes

https://www.certification.openid.net/log-detail.html?log=FwICw0NflJUoo0E&public=true : 15 minutes

https://www.certification.openid.net/log-detail.html?log=7k9wxc0sGnL3WSc&public=true : 60 minutes

https://www.certification.openid.net/log-detail.html?log=CknlUP804u6h1MV&public=true : 60 minutes

I do not see how CIBA provides any useful functionality to third parties if banks are allowed to reject expired id tokens used as hints, and if banks are allowed to set expiry times as short as 15 minutes.

I recommend either:

A) There are rules set that allow the id_token to be used as an id_token_hint after it has expired

or:

B) Banks are required to issue id_tokens with lifetimes of at least several days, or whatever is required to make the CIBA use cases work.

There are pros and cons of either solution, and it would be outside of OIDF's scope to make a recommendation of which should be picked.

[guilhermedecampo]

Hi @jogu we have approved (on Conseil) the id_token to be valid for at least 180 days (6 months) if banks wanna join CIBA.

[jogu]

@guilhermedecampo ah, thank you. We didn't know about that change. Where can we find information about it please? Are there any other changes we don't know about?

[guilhermedecampo]

We'll consolidate all data into a documentation and share with you soon.

[ErickRaidiam]

Hi,

Just a heads up on:

Signature should be validated on the account provider side. Just like the normal flows for rotations a new certificate should be added in the jwks list.

I think there's confusion on this point. On existing scenarios, the expiration time is, as Joseph showed, of little less than 1 hour so it's unlikely that a message will be signed with a valid certificate and then, the key will expire in this 1 hour timeframe.

However, here, when talking about a 180 days expiration date, and as keys expire within a year the following scenario is very likely to happen:

Day 0: ID_Token issued with JWT being signed by key with kid 12345, currently present on the jwks

Day 10: key with kid 12345 expired -> Key removed from the jwks by the directory keystores

Day 11: id_token is still valid according to expiration, however the key is no longer present on the JWKS active key stores, having been moved to the inactive one.

For example, on https://keystore.directory.openbankingbrasil.org.br/c5e51f16-3dc9-4cf0-a96d-16d073d4e4aa/inactive/application.jwks we can see that there's a key with kid:wDwr1MqbOYpt1fUyWnXhhjHGT7-zVM9yi2IkOiJC6JU which was expired on Sep 06 2022, meaning that it was moved on that date from the active keyset - https://keystore.directory.openbankingbrasil.org.br/c5e51f16-3dc9-4cf0-a96d-16d073d4e4aa/application.jwks

[guilhermedecampo]

It's a really good point @ErickRaidiam!

But since who issued the id_token is the account provider AND it's the one to check if it's valid. It could take the keys expired into account to make sure the id_token keep working.

Do you see another solution or another way to workaround this surely key expiration problem?

[ErickRaidiam]

Hi @guilhermedecampo

I agree with you here. I think it's just about writing the specification something broad enough to allow the OP to validate in which way he prefers. Something like:

• shall validate that the id_token_hint has been signed by the Authorisation Server's private keys using the public keys uploaded to the Participant Directory;
• shall conduct the id_token_hint signature validation irrespective of the certificate containing the public keys' validity status, accepting it, even if associated with an expired certificate.

And then we can note somewhere that every key uploaded into the directory will be present on either the active or the inactive keystore endpoint.

• https://keystore.directory.openbankingbrasil.org.br//application.jwks
• https://keystore.directory.openbankingbrasil.org.br//inactive/application.jwks

[guilhermedecampo]

Nice @ErickRaidiam,

I think if you all agree we can add those points into the documentation and consolidate the understandings about the id_token validation.

makes sense?

[bruno-f-assis]

Hi @ErickRaidiam

Squad CIBA has modified the second bullet in order to clarify that the account provider shouldn't accept every ID_token with any expiration date, but rather link the signature valdiation to ID_token's age. This should be a part of the account provider security policy.

Squad CIBA: "shall conduct the id_token_hint signature validation according to its security policies, accepting it, even if associated with an expired certificate that is within a time tolerance associated to the id_token validity (e.g. if the OP emits id_tokens with 6 months validity, it should expect signatures to be invalid for no much longer than 6 months). The OP is free to establish its own validation policies, but this specification recommends that the OP uses the id_token validity duration as a reference for signature verifications."