BK: Comment 1

Section 1

   While it is easy to implement, the encoding in the URI does not allow
   application layer security with confidentiality and integrity
   protection to be used.  While TLS is used to offer communication

nit: this wording is a little hard to read; it might be easier to
reorder to &#34;does not allow application layer security to be used to
provide confidentiality and integrity protection&#34;.

   The use of application layer security allows requests to be prepared
   by a third party so that a client application cannot request more
   permissions than previously agreed.  This offers an additional degree
   of privacy protection.

(side note) what would an example of such a third party be.  (We already
have the resource owner, the client, and the authorization server ...
maybe it&#39;s a fourth party?)

   Furthermore, the request by reference allows the reduction of over-
   the-wire overhead.

We only barely mentioned by-reference at this point (one line in the
Abstract), so I&#39;d suggest &#34;passing the request by reference&#34;.

   (4)  its development status that it is an RFC and so is its
        associated signing and encryption methods as [RFC7515] and
        [RFC7516]

nit: I&#39;d suggest &#34;its development status as a Proposed Standard, along
with the associated signing and encryption methods [RFC7515] [RFC7516].&#34;

   (c)  (confidentiality protection) The request can be encrypted so
        that end-to-end confidentiality can be provided even if the TLS
        connection is terminated at one point or another.

nit: TLS is always terminated at or before the user-agent, though.  So
maybe the user agent needs to get called out here as well (there could
of course be TLS termination earlier than the user-agent in some cases,
too).

   2.  When the client does not want to do the crypto.  The
       Authorization Server may provide an endpoint to accept the
       Authorization Request through direct communication with the
       Client so that the Client is authenticated and the channel is TLS
       protected.

How can you &#34;not want to do [the] crypto&#34; but still be doing TLS (with
crypto)?  Perhaps we&#39;re looking for &#34;not want to pay the additional
overhead of JWS/JWE cryptography on top of TLS&#34;?
(Source) [https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/](https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/)
Comments (4)
