On Fri, Apr 11, 2025 at 12:18:14PM +0200, Filip Skokan wrote: > > > Back to a general "freshness" mechanism. What if we designated an HTTP > Response Header parameter applicable to *any* AS HTTP response that carries > a currently accepted value? A client that regularly communicates with the > AS would always have a very likely usable value to use. Cold start clients > that perform discovery could get a value that way. The header value could > even carry a valid until timestamp or an expires_in delta value to let the > client know not to use an expired value. Much like in DPoP-Nonce case a new > header value received means to stop using the old one and use the new. And > to get a fresh value in the scenario where the value client has is expired > (based on the indicated delta or timestamp) the client can do a request to > the authenticated endpoint (e.g. PAR, or token endpoints) without the > expensive to generate credentials expecting an error response in which a > fresh value would be carried by HTTP Response Headers.
This looks an awful lot like how ACME (RFC 8555) manages nonces -- clients there need to provide a nonce with almost all requests, and get new ones back in almost all responses. A cold-starting client can hit a dedicated "request nonce" endpoint to bootstrap but in normal operation you get useful nonces from the other APIs you call and don't need to hit the dedicated endpoint very often. The details differ from there to here, of course, especially in terms of nonce lifetime, whether nonces can be restricted in scope to individual authenticated clients, etc., but the general principle is pretty analogous. > That's a long-winded way of saying, TL;DR, let's *consider *the > option of giving the AS the option to return a freshness challenge value in > every HTTP response via a header, have the header be structured to indicate > the value and its expiration, have the client behave right when new values > are received and, specific to Attestation-Based Client Authentication, tell > the client that if it doesn't have a valid challenge value to use - make > the request to the endpoint without credentials (or possibly with just a > client_id. We don't need to specify a new endpoint and end up with a > freshness mechanism that might be usable for future cases. Would AS > implementers tolerate the occasional client authentication error response > if it means no introduction of contentious endpoints? Another model for proving freshness of authentication that I do not see in this thread yet is to have the client sign a TLS Exporter value from the underlying connection. This gets uniqueness for free and is tightly scoped in time, but is complicated to implement in the presence of TLS-terminating load balancers and becomes hard to reason about if the freshness token needs to be conveyed further to other entities in a distributed system (which I suspect might be the case here, not having looked at the specific scenario). -Ben _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
