[Openid-specs-ab] Issue #2142: [Federation] - Expected Behavior for Client Resources when the OP can't validate its Trust Chain (openid/connect)

[Erick Domingues]

New issue 2142: [Federation] - Expected Behavior for Client Resources when the OP can't validate its Trust Chain
https://bitbucket.org/openid/connect/issues/2142/federation-expected-behavior-for-client

Erick Domingues:

One concern we have identified on using OIDC Federation for Open Finance Data Sharing Ecosystems is the potential for servers to inadvertently purge existing user consents due to an inability to verify the client's status within the federation

In open finance br/uk context, user consent to share data results in the creation of a Long-Lived Consent Object, allowing data access via a refresh token until such consent is revoked, something that extends beyond the current scope of OIDC. 

A worth noting incident on Open Finance Brazil, which uses DCR for registration, highlighted the risk of this issue. An RP recently deleted its Client with an OP, resulting in over a million Consents being automatically revoked, all of which will need to be re-authorized.

The OIDC Federation specification already brings guidance around validity re-evaluation[ \(Section 12.3\),](https://openid.net/specs/openid-federation-1_0.html#section-12.3) therefore, **we suggest adding a recommendation that ecosystems should make sure they define what should happen with Consent Objects \(Or Other Client Resources\), on the occasion that they exist, if Client Trust Chain cannot be validated.**

For Reference to the Open Finance UAE ecosystem, we are considering implementing a requirement to ensure the preservation of consent resources associated with a Relying Party for a minimum of 30 days following the expiry of the clients' last valid Entity Statement. 

‌