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

[Mike Jones <[e-mail]>]

Thanks for your useful review, Eric.  Proposed resolutions to all comments are inline prefixed by "Mike>".

From: OAuth [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Sunday, September 3, 2017 3:26 PM
To: [e-mail]
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

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"

Mike> Thanks - I will use this language.

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

Mike> I will add "If omitted, these authentication methods cannot be used."

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

Mike> There is no default.  I will add "If omitted, the set of supported languages and scripts is unspecified."

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

Mike> I will add client_secret_basic as the default - just like it already was for token_endpoint_auth_methods_supported.

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

Mike> I will add "If omitted, these authentication methods cannot be used."

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?

Mike> There is no obvious default.  Therefore, I will add "If omitted, the set of supported authentication methods MUST be determined by other means."

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

Mike> I will add "If omitted, these authentication methods cannot be used."

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?

Mike> I will add "If omitted, the authorization server does not support PKCE."

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

Mike> I will add "This path MUST use the "https" scheme."

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?

Mike> OAuth 2.0 [RFC 6749] also requires an RFC 6125 certificate validation, so this is in line with other uses of the OAuth protocol family.

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

Mike> This registry language closely follows that in OAuth 2.0 [RFC 6749] and subsequent OAuth specifications.  I'd rather keep them parallel unless something isn't clear.

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

As it says later in this section "Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the [e-mail] mailing list) for resolution."  

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

Are you talking about there being two spaces between the bullet character "o" and the items such as "Change Controller: IESG"?  That's what <list style='symbols'> does.  Or are you wanting more whitespace somewhere?  Please give more context because I'm not looking at this on Phabricator.  (I created an account "mbj" but it wanted me to install a second factor phone app, which seemed like a bit much...)

				Thanks,
				-- Mike