Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

Murray, Thanks very much for your comment.

My replies inline:

On Wed, Aug 12, 2020 at 4:56 PM Murray Kucherawy via Datatracker <
noreply@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-oauth-jwsreq-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The directorate reviews are from 15 or more versions ago.  I wonder if
> returning documents like this should be sent through the directorates
> again as
> matter of course.
>
> Abstract: "... the communication through the user agents are not ..." --
> s/are/is/
>

Thanks for pointing out.

>
> Section 1 expressly cites two IANA URLs.  I suggest simply naming the
> registry
> or sub-registry; the URLs might not be permanent.  Or if you like the URL,
> do
> it as a reference, as you did with [IANA.MediaType].
>
> Good point. Will do.

> The two bullets at the end of Section 1 toggle between "crypto" and
> "cryptography".  I suggest picking one, preferably the latter (as did the
> rest
> of the document).
>

Ditto.

>
> In Section 3, should URI and URL include references to their defining
> RFCs?  I
> realize a reader familiar with this space probably knows those terms, but
> they
> seem to be the only acronyms without a reference here.
>

Good point. It will certainly improve the consistency.  Will do.

> When would an implementer legitimately disregard the SHOULD in Section 4?
>

E.g., in the case where there is only one client and  the server in the
system,
it may be redundant to have `iss` and `aud`.

> As Benjamin Kaduk also expressed, I'm a little puzzled by this text in
> Section
> 5.2: "The "request_uri" value MUST be reachable by the Authorization
> Server."
> Is this part of the protocol?
>

Please refer to my response to Ben.

>
> All of the subsections of Section 9 say: "This specification adds the
> following
> values to the "OAuth Parameters" registry established ..." but they all are
> actually modifying different sub-registries.  I suggest naming the
> sub-registries explicitly.  I realize the subsection titles have it right,
> but
> this line of repeated prose had me squinting a bit.
>

OK. Good point. Thanks.

>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en