Add explanatory text on `aud`

Coming back to this. It seems like you still need to add the explanatory text about "aud" that John referred to upthread. After that, I believe we're done and can ship it to the RFC Editor. -Ekr

On Fri, May 11, 2018 at 11:52 AM Eric Rescorla ekr@rtfm.com wrote: Great. Then I think it would be good to document why that cant be replaced. It sounds like that's just a matter of new text. -Ekr

On Fri, May 11, 2018 at 11:49 AM, John Bradley ve7jtb@ve7jtb.com wrote:

Inline

On May 11, 2018, at 3:38 PM, Eric Rescorla ekr@rtfm.com wrote:

On Fri, May 11, 2018 at 11:35 AM, John Bradley ve7jtb@ve7jtb.com wrote: Hi Eric, I am assuming that are referring to the base URI. I'm referring to the URI in the HTTP request where the JWT is being carried. Is that the base URI? Yes the bit before the query parameters.

We do effectively have that with aud (audience). That claim is a SHOULD in section 4.
In some profile of OAuth it is already defined as a logical name rather than the base URI of the authorization endpoint. So yes the token needs to be audience restricted. Perhaps because this comes from openID Connect where aud is required and clearly defined as the logical name for the AS we should say something more about what you should use as the value of aud. I think that would be helpful. Once we have OAuth discovery done we could use the path of the AS discovery document like we do in connect. The banking people are keen on request by reference, It is used in the Financial Services API Profile of OpenID Connect. We can put in a reference. I have no objection to it being there. I just want people to be able to undewrstand it. I will have a look at 10.4. John B.

On May 11, 2018, at 3:18 PM, Eric Rescorla ekr@rtfm.com wrote:

I realized that because Stephen is gone I need to vote "yes" on this, so I have reviewed it myself.

In general, it seems fine, but I have one question: you copy the parameters into the JWT, but I don't see you copying the URI in there, so doesn't that allow attacks? What am I missing?

A few minor comments: S 1.
      status to the end-user, who would have some assurance as to the
      legitimacy of the request when authorizing it.  In some cases,
      it may even be desirable to skip the authorization dialogue
      under such circumstances.

 There are a few cases that request by reference is useful such as:
Can you provide a cite for "request by reference"

S 10.4.
 should be created as a measure to address the risk.
10.4. Risks Associated with request_uri
 The introdcution of "redirect_uri" introduces several attack
 possibilities.
This section seems to be about "request_uri" and not "redirect_uri", so it's confusing.

Comments (3)