[Openid-specs-ab] Issue #1485: [Resolve Entity Endpoint] dynamic update of trust chains (openid/connect)

[peppelinux]

New issue 1485: [Resolve Entity Endpoint] dynamic update of trust chains
https://bitbucket.org/openid/connect/issues/1485/resolve-entity-endpoint-dynamic-update-of

Giuseppe De Marco:

Taking up the above [here](https://bitbucket.org/openid/connect/issues/1449/an-endpoint-to-receive-an-update-signal) with the extension of the Endpoint Resolve Statement.  
  
**Requirement**  
Equip OIDC Federation-based infrastructures with a mechanism to update metadata from and to all the parties, in real time.  
  
**Solution**  
The Resolve Statement Endpoint may optionally enable a POST method, protected by private\_key\_jwt or any other client authentication as necessary requirement.  
  
The client authentication protects the trigger of a new Trust Chain evaluation, for a given subject and a given trust anchor, to the Resolve endpoint.  
  
When a leaf updates its Entity Configuration it may requests to its superiors \(authority\_hints\) to update the Trust Chain related to itself.  
  
The superior that receives this request, authenticates the client \(eg: private\_key\_jwt\) and triggers a renewal of the Trust chain for the given subject. This obtain the final metadata and the trust marks of the requestor, and consequently updates the result of the entity statement resolve response, relative to the descendant subject.  
  
The leaf should execute this call to all corresponding superiors identified on the path to one or more trust anchors.

This would result in the Trust Anchor getting the final metadata and trust marks valid for each leaf, even if the leaf is not one of its direct descendant. As a result, the Entity Resolve endpoint responses will always be up to date. A participant in a federation could trigger an update to all the federation resolve endpoints as well, exposed by third-party systems, at any occurrence.  
  
**Result and benefits**  
1\. All the leafs in a federation could updates their entity configurations without incurring problems of temporary misalignment.  
2\. In the case that all the entities exposes the resolve entity endpoint with the POST method here proposed, a RP that got evidence of the misalignment of its metadata to a OP could trigger a new trust chain processing, relate to itself, to the OP.  
  
**Security considerations**  
  
**replay attacks**: the private\_key\_jwt should have an expiration time in seconds, not exceeding a time limit, to reduce the danger that the theft of this could somehow become a vehicle of a propagation attack by triggering trust chain validation to and from many parts. The **cache duration** of a Resolve entity endpoint HTTP POST response, related to a leaf and a trust anchor, must be equal in seconds to the difference of the **exp** - **iat** values, contained in the **private\_key\_jwt**. This prevents that a JWT used in a private\_key\_jwt could be replayed over and over to the same endpoint and be veicle of a resource consumption attack. This would cause a leaf that needs frequent updates to configure the exp value of private\_key\_jwt as low as possible, making the cache life low.  
  
**rate limiting and throttling**: see [https://bitbucket.org/openid/connect/issues/1416/security-considerations-for-federation-api](https://bitbucket.org/openid/connect/issues/1416/security-considerations-for-federation-api)  
  
the question is whether to allow only descendants to trigger this call, and then delegate the superiors to the trigger at their superiors or consider this proposal as it is.