[OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

[Eric Rescorla <[e-mail]>]

Hi folks,

Note: the original of this review is on Phabricator at:

  https://mozphab-ietf.devsvcdev.mozaws.net/D7

If you want to see comments in context, you can go there. Also,
you can create an account and respond inline if you like.
If you elect to, let me know if you run into problems.

-Ekr


I have marked a number of places where it seems like you either need
defaults or need to indicate what the semantics are if missing


   This metadata can either be communicated in a self-asserted fashion
   or as a set of signed metadata values represented as claims in a JSON
I assume "self-asserted" in this case means "asserted by the server origin
via HTTPS"


Line 222
      authentication methods.  Servers SHOULD support "RS256".  The
      value "none" MUST NOT be used.
What's the default if omitted?


Line 235
      represented as a JSON array of BCP47 [RFC5646] language tag
      values.
What's the default if omitted?


Line 267
      "OAuth Token Endpoint Authentication Methods" registry
      [IANA.OAuth.Parameters].
What's the default if omitted?


Line 275
      "client_secret_jwt" authentication methods.  The value "none" MUST
      NOT be used.
What's the default if omitted?


Line 288
      Access Token Types" registry [IANA.OAuth.Parameters].  (These
      values are and will remain distinct, due to Section 7.2.)
What's the default if omitted?


Line 296
      "client_secret_jwt" authentication methods.  The value "none" MUST
      NOT be used.
What's the default if omitted?


Line 304
      challenge method values are those registered in the IANA "PKCE
      Code Challenge Methods" registry [IANA.OAuth.Parameters].
What's the default if omitted?

Line 343
   MUST be registered in the IANA "Well-Known URIs" registry
   [IANA.well-known].
IMPORTANT: Shouldn't this be required to be HTTPS

Line 500
   client MUST perform a TLS/SSL server certificate check, per RFC 6125
   [RFC6125].  Implementation security considerations can be found in
   Recommendations for Secure Use of TLS and DTLS [BCP195].
Hmm.... I'm unsure about whether this should be a citation to 2818. Is the
general feeling that 6125 superceded 2818?


Line 564
   The following registration procedure is used for the registry
   established by this specification.
This section seems like it needs RFC2119 language


Line 568
   Values are registered on a Specification Required [RFC5226] basis
   after a two-week review period on the [e-mail]
   mailing list, on the advice of one or more Designated Experts.
What happens if you don't do anything within two weeks.


Line 756
   o  Change Controller: IESG
   o  Specification Document(s): Section 2 of [[ this specification ]]
Extra whitespace.