[Federation] - Expected Behavior for Client Resources when the OP can't validate its Trust Chain

[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), 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.

‌

[Vladimir Dzhuvinov]

Thank you for posting this consideration. The transient nature of Trust Chains and what that means for applications is definitely something that applications & deployments will need to consider. In our implementation we’ve been considering to make this behavior configurable. But that may not be enough, because trust chain validation can fail for network / temp resolution reasons as well as for reasons like the TA removing the RP from its trust list. Have you considered this?

OPs may also expire registrations when the trust chain used for the registration has expired, to clean up client resources without re-evaluating the trust in the RP. So the trust chain expiration also needs to be taken into account.

There’s also the related question what to do with the refresh token grant.

So, there are several things to think about

[Erick Domingues]

The way we are planning on handling this on OPF UAE is by introducing an additional property in the RP Metadata, labelled "status," with three potential values: "Active," "Inactive," and "Suspended." This will provide a clear indication of the current state of each entity in the trust chain.

In conjunction with this, we are proposing two clauses to be added to the Registration Framework Standards of OIDC Federation w/ Automatic Registration, which all participating Authorization Servers would need to follow:

1. Upon successful registration of a new Relying Party, the Authorization Server shall maintain the integrity of all the consent resources associated with it, preserving it for a minimum duration of 30 days after either

   1. Its status has been set as “Inactive” or
   2. The expiration of the Relying Party’s latest verified Entity Statement;

2. On the occasion that the Authorization Server cannot verify the Relying Party Metadata—due to inaccessibility or corruption of the Entity Statement—the Server shall transition the affected Client to a ‘Suspended’ state where no new Access Tokens can be issued but all linked consent resources, grants and refresh tokens remain intact;

I understand that implementing these measures may pose challenges for some OP Service Providers. However, in the case of UAE, the number of Service Providers is minimal, simplifying the alignment of these requirements. Additionally, all Relying Party Entity Statements will be centrally served by our Federation Operator, the Raidiam Trust Framework, providing a high level of control over the provided metadata and its availability.

[Vladimir Dzhuvinov]

Thanks for these very concrete proposals.

We definitely need to have a section with these considerations and your proposal can be used as a nice basis for that. As for requiring a min duration of 30 days, I think we should best leave this to individual federation profiles to decide. So this could become a parameter in a UAE OPF profile. Consent data can be a subject of privacy laws.

[Giuseppe De Marco]

Erick we’re trying to analyze the proposal in this issue https://bitbucket.org/openid/connect/issues/2109/federation-advanced-listing-endpoint where we’re introducing the properties about the revoked immediate subordinates as well. Please join within the thread.