Draft -07 https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 contains
these proposed resolutions. The only change is that in places where I'd
previously proposed to say "If omitted, these authentication methods cannot be
used" I now say "This metadata entry MUST be present if either of these
authentication methods are specified in the
"{token,revocation,introspection}_endpoint_auth_methods_supported" entry. No
default algorithms are implied if this entry is omitted."
I made the change because saying that they cannot be used isn't actually
correct. This information could always have been communicated out-of-band to
the metadata.
-- Mike
-----Original Message-----
From: Mike Jones
Sent: Tuesday, September 5, 2017 4:12 PM
To: 'Eric Rescorla' <e...@rtfm.com>; oauth@ietf.org
Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
Thanks for your useful review, Eric. Proposed resolutions to all comments are
inline prefixed by "Mike>".
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, September 3, 2017 3:26 PM
To: oauth@ietf.org
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:oauth-ext-rev...@ietf.org
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 i...@ietf.org 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
