"claims_redirect_uri

OPTIONAL. The URI to which the client wishes the authorization server to direct the requesting party's user agent after completing its interaction. The URI MUST be absolute, MAY contain an application/x-www-form-urlencoded-formatted query parameter component that MUST be retained when adding additional parameters, and MUST NOT contain a fragment component. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint (either using a static process or throughRFC7591 (at line 1749) or [OIDCDynClientReg]). The claims redirection URIs of a client MUST be registered distinct from the client's redirection URIs as used at the authorization endpoint during redirect-based OAuth flows. If the URI is pre-registered, this URI MUST exactly match one of the pre-registered claims redirection URIs, with the matching performed as described in Section 6.2.1 of RFC3986 (at line 1756) (Simple String Comparison)."

She commented: "Section 3.6.2, in the “claims_redirect_uri” description, I was a bit confused about what is a MUST and what is a should? Is it a MUST that the client pre-registers the claims_redirect_uri? Then the sentence, “If the URI is pre-registered” should not have an If?"

First, we could improve the language generally to do away with the passive and ambiguity (some of which came from the original OAuth passage).

But second, is it still necessary for us to be segregating UMA client redirect callback URIs from OAuth client callback URIs? With an UMA client adhering to a formal UMA extension grant of OAuth soon enough, will it be a distinction without a difference?

Here's a revision that attempts to fix the former problem and also keep the original semantic, in case we need it. Changes bolded. The sentence in bold red could be removed if we think it's pointless now.

Discussion and comment welcome, especially prior to next Friday's call so that we can take care of this issue expeditiously. Thanks!