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

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2142

Original Reporter: 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.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: vdzhuvinov

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 :slight_smile:

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: 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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: vdzhuvinov

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

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.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

Probably this could be more close to this: https://bitbucket.org/openid/connect/pull-requests/731

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

If the Trust Chain can't be validated, you should not proceed, as you haven't established trust in the other entity.

It sounds like you're talking about this occurring due to a configuration error, in which case the configuration will need to be corrected. Is there a deeper issue than this?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: Erick_Domingues

The root issue arises when an RP Entity Statement is unreachable and the OP, rather than merely blocking calls from the RP, assumes that it has been revoked from the Ecosystem.

In Open Finance Brazil, we have several RPs managing millions of active refresh tokens and consents on various OPs. It is crucial to ensure that these consents are not revoked unless absolutely necessary.

I believe the suggestion raised on https://bitbucket.org/openid/connect/pull-requests/731 would cover this, as we could define a policy that only institutions placed on the Revocation List should have their consents revoked. All the others would at most need their Auth Requests denied.

Thanks!

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: rolandh

My understanding of the problem you put forth is that you are talking about the lifetime for consent.

Basically, can consent still be valid if the entity, that it was constructed for, is not around anymore ?

This is not as I see it an OpenID Federation problem. This is a problem that should be adressed in the application protocol profile.

It is definitely possible to specify that consent constructed by an OPs should continue to be valid for a the grace period, after the RP that is connected to the consent has dopped out of the federation. This demands some special code to be added to all OPs but it can be done.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: vdzhuvinov

Erick, hi.

Today we briefly chatted about this issue and an ideal strategy to address this in the Federation spec.

We concluded that can be a general issue in applications that use Federation, and based on established trust, issue credentials or undertake some other action, like store consent. So, it’s a general problem that is worth mentioning and that may affect other protocols, besides OpenID Connect.

‌

[selfissued]

Status of entities is a topic being worked on in the now-adopted specification https://openid.net/specs/openid-federation-extended-listing-1_0.html . Its repository is at https://github.com/openid/federation-extended-listing . @EkkeErick , @MichaelFraser1999 , and @yaromin , should we address this issue in the new specification?

[selfissued]

The revoked status in https://openid.net/specs/openid-federation-extended-listing-1_0.html is one aspect of status. If we want more status attributes, that seems to be the place to pursue them.

Also, consent records and other client state are not part of OpenID Federation but are a valid extension for some ecosystems and protocols @EkkeErick, do you want to join an OpenID Connect working group call and discuss how to achieve what you need? The call schedules are listed at https://openid.net/wg/connect/.

Because client state is out of scope for the core OpenID Federation protocol, I plan to close this issue in a week unless reasons to keep it open are brought forth. Thanks.