<div dir="ltr"><div>What's the idea behind a client registering request_uris that include fragments? <br><br></div>I thought the fragment thing was to help with caching and knowing when to re-fetch the content. But I don't see how that works with per-registration.<br>

<br><dl><dt>request_uris</dt><dd>
            OPTIONAL.
            Array of <tt>request_uri</tt> values that are
            pre-registered by the RP for use at the OP.
            Servers MAY cache the contents of the files referenced by these URIs and not
            retrieve them at the time they are used in a request.
            OPs can require that <tt>request_uri</tt> values used
            be pre-registered with the <tt>require_request_uri_registration</tt>
            discovery parameter.
          
</dd><dt><br></dt><dd>
            If the contents of the request file could ever change,
            these URI values SHOULD include the base64url encoded SHA-256 hash value of
            the file contents referenced by the URI as the value of the URI fragment.
            If the fragment value used for a URI changes, that signals the server
            that its cached value for that URI with the old fragment value
            is no longer valid.
</dd></dl><br><div><br><br></div></div>