An endpoint to receive an update signal from a descendant

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

[Tom Jones]

I suggest that you check out the specs on shared signals and events. https://openid.net/wg/sse/

[Giuseppe De Marco]

Thank you Tom, I believe that it would be the best choice, even to a better integration of all the oidc specs ecosystems

[Roland Hedberg]

Notifications of changes has by design been left out of the spec. We had to draw the line somewhere and this ended up on the outside.

This doesn’t mean that we where correct in our choice.

Notifications can be implemented in many different ways and I’m not sure we want or need to pick one.

[Michael Jones]

I agree with Roland’s analysis of the situation. I propose that we close this issue on that basis.