[The Infrastructure of Trust - Federation API endpoints] - Trust Evaluation

[pietroACN]

Specification states that "The revocation of an Entity is made with the unavailability of the Entity Statement related to it" Link

If applied as defined, this will invalidate all attestations issued by this entity BEFORE revocation, and this process may be incorrect (e.g. a University closes, thus related entity is revoked: this doesn't mean that attestations issued are not anymore valid. In general, removing an entity will lead to instability of the ecosystem, thus entities should be always present, in an historical federation chain or within existing chain with added 'expiration/revocation date' .

[peppelinux]

it may depend about the revocation reason

at the current state using the endpoints defined in federation we only can evaluate the revocation in the present, without any revocation reason about a subject

for this reason this proposal was brought in openid federation, where you perspective is also required: https://bitbucket.org/openid/connect/pull-requests/731

[pietroACN]

As we have no answer in https://bitbucket.org/openid/connect/pull-requests/731 I suggest to proceed here.

[peppelinux]

@fmarino-ipzs is requested to say something before any action

I'll try to reach OpenID Federation authors to gather additional information about how/when to proceed

[SaraConsoliACN]

Regarding PR #731 opened in openID repo, we noticed that has been declined as it was supposedly handled by the new OpenID Federation Extended Subordinate Listing.

As we believe that this issue has not been addressed in the new text, while some elements have been addressed here we propose a new text for this stream: There are events when keys are not available to check the entire trust chain, as follows: 1 - The credential issuer changes its keys (the previous keys must be valid for the validity period), this can be addressed using the Federation Historical Keys Endpoint. 2 - The credential issuer changes the types of credentials issued (removing one or more is the critical case) We need to take in consideration that this would be triggered in some cases at intermediate/root level, thus may be 'forced' by an upper authority. Previously issued credentials within previous scope must be valid for their validity period. In this case is not clear if can be addressed using the Federation Historical Keys Endpoint, as the entity managing it would be the same. 3 - The credential issuer is merged with another issuer. In this case we would not only need to have a Federation Historical Keys Endpoint but as well something like using the Federation Historical Entity Endpoint. In this case who manages this endpoint? 4 - The credential issuer is no longer active (this may happen for several reasons). As for the previous case, we would need a Federation Historical Entity Endpoint but surely managed by the upper authority. 5 - This may happen not only for the leaf (credential issuer) but similar may happen for any intermediate or root entity. This means that in some cases the root/trust anchor could be the entity entitled to manage the Federation Historical Entity Endpoint Thus in the last 3 cases, the root authority, or an authority mandated by the root authority, MUST store the keys of the trust chain. In the event of an issue involving any actor within the trust chain, the root authority is responsible for maintaining the trust chain history of the entity for a period established by law.

[peppelinux]

The federation entities registration events endpoint was introduced in the draft below, also adopted in the connect A/B WG within the openid foundation

https://github.com/openid/federation-extended-listing