Add a mechanism for client-triggered early metadata retrieval

[TakahikoKawasaki]

While authorization servers can calculate the lifetime of client metadata using the methods described in RFC 9111 HTTP Caching and continue to reuse the retrieved metadata until the calculated expiration time is reached, client applications may sometimes want authorization servers to re-fetch the metadata before that expiration time.

Could we introduce a mechanism that allows client applications to trigger such early metadata retrieval? For example, what about introducing a new request parameter like cimd_max_age, similar in concept to the max_age parameter defined in OpenID Connect Core 1.0?

This issue is related to PR #29 "Improve documentation for development usage and expiration of clients", I think.

[panva]

Just prescribing to use a "max-age" HTTP Response Header would probably be cleaner than introducing a new server metadata.

[TakahikoKawasaki]

@panva Thank you for your comment.

This is not a proposal to introduce new server metadata, but rather a new runtime request parameter.

I implemented CIMD with a caching mechanism that leverages existing HTTP semantics, including max-age. However, I still believe that having a mechanism to trigger earlier metadata retrieval would be beneficial.

OpenID Federation defines the trust_chain request parameter. When included in an authorization request, it instructs the authorization server to update the client metadata using the provided trust chain, even if the cached trust chain has not yet expired. I hope that CIMD can also offer a similar mechanism to trigger early metadata retrieval, analogous to the trust_chain request parameter.

[panva]

Ah, sorry, then let me rephrase.

Just prescribing to use a "max-age" HTTP Response Header from a CIMD response would be cleaner than introducing a new request parameter that could actually be at odds with an existing max-age on the response and then we'd have to prescribe which of the max ages to use.

A parameter like so could also be abused to force AS cache invalidation which could cause to a whole sorts of otherwise avoidable issues. If the only thing the server trusts to control its cache ttl is a max-age response header than that's one less moving piece.

[aaronpk]

On reading the title, I thought you were going to suggest a totally new endpoint the client could use to request updated metadata fetching, not during authorization.

I agree with Filip's concerns about adding a parameter in the authorize request. Ultimately an AS would decide its own rate limit of the max age parameter anyway to avoid too many requests from clients that always set it to 0.

[TakahikoKawasaki]

I'm not suggesting a new endpoint, which would be heavyweight. 😅

Perhaps the name cimd_max_age wasn't ideal. What I really wanted is a mechanism that forces the authorization server to re-fetch client metadata. (Like "super reload" of web browsers)

During client application development, developers may not be able to properly configure the web server that publishes the client metadata—either due to lack of knowledge or insufficient permissions. In such cases (including simple mistakes like forgetting to set max-age or accidentally setting it too long), even if the client metadata is updated frequently during development, the authorization server will continue using the cached metadata, which slows down the development process. I wanted a way to address this situation.

[panva]

That's a very coincidental problem to have to deal with. As a developer i might as well just randomize the URLs I use during development then can't I?

[aaronpk]

My point is even if you want to force the AS to reload the metadata, the AS might always have a policy that prevents reloading at some interval. At most this new parameter would be a suggestion, and we already have a mechanism to suggest lifetime of the metadata in the HTTP header.