[Openid-specs-ab] Issue #1449: An endpoint to receive an update signal from a descendant (openid/connect)

[peppelinux]

New issue 1449: An endpoint to receive an update signal from a descendant
https://bitbucket.org/openid/connect/issues/1449/an-endpoint-to-receive-an-update-signal

Giuseppe De Marco:

In OIDC Federation, a federation entity cannot become aware of a change in the entity configuration of its descendant until it queries the **.well-known/openid-federation** endpoint of this.

Similarly, if an intermediary updates the public key of a descendant through a web registration procedure mediated by an authorized user, there is no way to let his superiors know.

If we obtain an endpoint of notification of a change, sent by a descending subject to its superiors, we could propagate update signals to higher entities. this endpoint MUST be protected by private\_key\_jwt or any other client auth.

If a trust anchor exposes a Resolve Statement Endpoint, these signals would offer evidence of upgrade requirement of the trust chain of a leaf.

Example  
1\. a leaf updates its redirect\_uris claim  
2\. the leaf sends an update signal to its superiors  
3\. the superiors may update the trust chains related to the leaf to get the final metadata of this  
4\. the superiors propagates the update signal of the leaf to their superiors and so on until the trust anchor will get the signal  
  
The request may be

```
POST /update HTTP/1.1
Host: that.superior.authori.ty
Content-Type: application/x-www-form-urlencoded

client_id=https://that.le.af& 
client_assertion=eyJhbGciOiJIUzI1NiIsInR ...&
sub=https://that.le.af
iat=1646092969
```

  
The superior in turn would send this signal at its superior’s update endpoint, with its own client authentication and keeping the iat and sub attributes unchanged from the original request.