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

Eric Rescorla <ekr@rtfm.com> Sat, 23 September 2017 19:59 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACD61323B4 for <oauth@ietfa.amsl.com>; Sat, 23 Sep 2017 12:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HysPdla5CuTG for <oauth@ietfa.amsl.com>; Sat, 23 Sep 2017 12:59:13 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3851320D9 for <oauth@ietf.org>; Sat, 23 Sep 2017 12:59:13 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id v72so2631395ywa.3 for <oauth@ietf.org>; Sat, 23 Sep 2017 12:59:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xj0EYZQylnpGcUcNATwTj76cUg/BgvWBwMqMeil/fws=; b=QgExB27JZP707aI23G0Y14L8X2B/F3oljMgqg8dHcb1YCE6Mx/2bjHUFAGug/tioV+ F3y9biAfVwdWAIMWR7nca2cUU24VGK7rk/9ABMhVkO+ElUXWZWLg5vX2ZuF3nPWU0+ff 0wvrnUYSCa7Wuwevumv3AxKKEAfpSeeEbBwh7qKXQ0BUGb6Ubt7otdoYVoPPRR8A/8/b Micsxrt0o3aNZkj87we0FEii1VND7+ypX27I1p/lOSP3uPjRqb4CVn+zwFKBitajUygn NTcrh0e7MgjAeBLckk8CA8hlPJy1jGr7cVNvkRlZVFYiDHfqyVk8gUPTcIqrRdc1DEmw WBgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xj0EYZQylnpGcUcNATwTj76cUg/BgvWBwMqMeil/fws=; b=VyLBiq6H9iMNVOqmjwM6zlMFKAPlH8nPcMUFbKDrwrOLDS/3gBu1DSBGDT+HjUQesq 6ChfpFNiDM/erHT0H21DKg2272a/uMuyshd/TIs+0+eEOooBa2nBVmf4RXsK/K8VQg0b MFy874gnE1iNrdYXbywDdKw9VhwZsigltI6xmX+oDgiETVRTUCzrwVR96DNEPpBWuHjz 2lgEo0peq/3gsDqFBt40Zs/O5ku+CXdLzwQ/JcKKMLLdbCEmuPjxqxt0wbAO4c6TqSdG 57eAWtHQ3tAHkXgizauRFifseTt5eEHymEh/MaN58Ay7OvRsg7F7HzzF3C6spQdd1N/d qDzw==
X-Gm-Message-State: AHPjjUjcQCPf9lezr24Ng1gMh9Ijqfifjwl0iDoyCIjFs2Bm1EYNcvc5 EWzaSo0lb6KIyx8r9vGHjnisOvah/rt83c7gdUJd/Q==
X-Google-Smtp-Source: AOwi7QDm2nBUJOxDX56yLw/mSfJflqcEcaxtq1p3Z+cRhRY0sukDzGD0EUVhRCJymo0bLydOS+c9kU4oA1faw4TZIRI=
X-Received: by 10.37.132.73 with SMTP id r9mr1836291ybm.165.1506196752598; Sat, 23 Sep 2017 12:59:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Sat, 23 Sep 2017 12:58:32 -0700 (PDT)
In-Reply-To: <CY4PR21MB0504936D69D2BC6DBD4A3E0FF5680@CY4PR21MB0504.namprd21.prod.outlook.com>
References: <CABcZeBP8G0L8+X0ddvEHng=R+eahG+KsKG9b2_BA7Si1Cd4MJQ@mail.gmail.com> <BN6PR21MB0500E18894881EFD5AD4386FF5960@BN6PR21MB0500.namprd21.prod.outlook.com> <BN6PR21MB0500FB3686ACD172BA1767BCF5940@BN6PR21MB0500.namprd21.prod.outlook.com> <CY4PR21MB0504936D69D2BC6DBD4A3E0FF5680@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 23 Sep 2017 12:58:32 -0700
Message-ID: <CABcZeBNVnPiW5J5c5x0Tdc9g6+B7KJ_qzzoB29jQaLdncgwf9w@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e0826fee4669ea40559e0c26c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/775AWiEwbbzzMdwUQlHtB0ggnrw>
Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Sep 2017 19:59:16 -0000

Hi Mike,

These changes look good. I have pushed the last call button.

-Ekr






On Mon, Sep 11, 2017 at 12:35 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> Eric, I believe that https://tools.ietf.org/html/
> draft-ietf-oauth-discovery-07 addresses all your comments.  Thanks for
> them again.
>
> If you agree, can you please progress the document to the next step?
>
>                                 Thanks,
>                                 -- Mike
>
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Thursday, September 7, 2017 2:25 PM
> To: Eric Rescorla <ekr@rtfm.com>om>; oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
>
> 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' <ekr@rtfm.com>om>; 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-bounces@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-review@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 iesg@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
>