Confusing JAR example using `redirect_uri` Client Identifier Prefix

[kitakaze-kan]

Summary

Section 5.4 includes a non-normative Authorization Request example where:

• client_id uses the redirect_uri: Client Identifier Prefix
• the request is shown as a Request Object (JWT), implying JAR usage

However, the specification elsewhere clearly states that requests using the redirect_uri Client Identifier Prefix cannot be signed, because the Wallet has no way to obtain a trusted public key for verification.

This makes the example potentially confusing for implementers.

---

Relevant Spec Text

From the Client Identifier Prefix section:

Requests using the redirect_uri Client Identifier Prefix cannot be signed because there is no method for the Wallet to obtain a trusted key for verification.

At the same time, Section 5.4 shows a Request Object example with:

"client_id": "redirect_uri:https://client.example.org/cb"

---

Issue

Even though the example is non-normative, it may be interpreted as allowing signed Request Objects (JAR) with client_id = redirect_uri:..., which is not practically verifiable by a Wallet and appears inconsistent with the normative text.

Thanks in advance!

[charsleysa]

From my understanding, Request Objects (JAR) do not need to be signed, so you can have an unsigned Request Object JWT.

This would mean the text is consistent.

[kitakaze-kan]

@charsleysa
Thanks for the explanation — that makes sense, and I agree that Request Objects do not necessarily have to be signed, and that unsigned Request Objects are possible.

My concern is more about how the current example may be read by implementers.

In Section 5.4, the text introducing the example says:

“Where the contents of the request query parameter consist of a base64url-encoded and signed (in the example with RS256 algorithm) Request Object.”

Since this wording explicitly mentions a signed Request Object and even names a signing algorithm, an implementer reading this example may reasonably assume that the example represents a signed Request Object.

At the same time, elsewhere in the spec the redirect_uri Client Identifier Prefix is described as not being usable with signed requests, because the Wallet has no way to obtain a trusted verification key.

Because of this, I found the combination a bit hard to interpret, even understanding that the example is non-normative and that unsigned Request Objects are allowed.

Perhaps a small clarification in the example text (for example, avoiding mention of a signing algorithm here, or explicitly stating that the example is unsigned) could help make the intended interpretation clearer for readers.

Thank you again for the clarification and for considering this feedback — I hope it can help improve readability for implementers.