Right now we cache use_as_origin per Chrome lifecycle (a static list that is owned by a singleton).

We dont do any general DAL caching, so it depends on the DAL servers response.

I dont think these are things that would change everyday though. So it does make sense to cache them for longer durations imo and would definitely make things easier. The problem is defining the duration and justification.

Does DAL response have cache header?

Following the sample code at https://developers.google.com/digital-asset-links/v1/samples, here is the response for the example URL:

$ curl -vvv https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=http%3A%2F%2Fexample.digitalassetlinks.org&relation=delegate_permission%2Fcommon.handle_all_urls                                                                                          
[...]
> GET /v1/statements:list?source.web.site=http%3A%2F%2Fexample.digitalassetlinks.org HTTP/1.1
[...]
< HTTP/1.1 200 OK
[...]
< Content-Type: application/json; charset=UTF-8
< Vary: X-Origin
< Vary: Referer
< Date: Fri, 23 Jun 2017 08:58:16 GMT
< Cache-Control: private
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Transfer-Encoding: chunked

So, according to Chrome's caching behavior, the response is never fresh in the cache, but is cacheable, which doesn't help here as there are no validators.