Re: [Ace] [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-ace-oauth-authz-38: (with COMMENT)

Seitz Ludwig <ludwig.seitz@combitech.se> Fri, 16 April 2021 06:31 UTC

Return-Path: <ludwig.seitz@combitech.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012663A1853; Thu, 15 Apr 2021 23:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 22AeEgmnyMy6; Thu, 15 Apr 2021 23:31:21 -0700 (PDT)
Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B061F3A1851; Thu, 15 Apr 2021 23:31:20 -0700 (PDT)
Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.7/8.14.7) with ESMTP id 13G6VFPH026076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Apr 2021 08:31:15 +0200
Received: from corpappl17779.corp.saab.se (corpappl17779.corp.saab.se [10.12.196.86]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 13G6V5r0007380 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 16 Apr 2021 08:31:05 +0200
Received: from corpappl17773.corp.saab.se (10.12.196.80) by corpappl17779.corp.saab.se (10.12.196.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 16 Apr 2021 08:31:04 +0200
Received: from corpappl17773.corp.saab.se ([fe80::20a9:e9fa:54a3:2afd]) by corpappl17773.corp.saab.se ([fe80::20a9:e9fa:54a3:2afd%17]) with mapi id 15.02.0792.013; Fri, 16 Apr 2021 08:31:04 +0200
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: =?utf-8?B?W0VYVEVSTkFMXSDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJh?= =?utf-8?Q?ft-ietf-ace-oauth-authz-38:_(with_COMMENT)?=
Thread-Index: AQHXHyuZU/A3KOOoPkeRpDWfQb0fYKq21Wgw
Date: Fri, 16 Apr 2021 06:31:04 +0000
Message-ID: <17c975cd75bb4449a401c799672b1a6a@combitech.se>
References: <161642497935.28459.6337296577160925255@ietfa.amsl.com>
In-Reply-To: <161642497935.28459.6337296577160925255@ietfa.amsl.com>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [136.163.101.124]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 13G6V5r0007380
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=1.594, required 5, BAYES_40 -0.00, HELO_NO_DOMAIN 0.00, KAM_ASCII_DIVIDERS 0.80, RDNS_NONE 0.79, URIBL_BLOCKED 0.00)
X-Saab-MailScanner-SpamScore: s
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1619159465.18262@8Fe26SCcXCOWmZXm5FELjw
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/d2mMfVxrgfE5Ua6hlrDRvVpOqkk>
Subject: Re: [Ace] =?utf-8?q?=5BEXTERNAL=5D_=C3=89ric_Vyncke=27s_No_Objection?= =?utf-8?q?_on_draft-ietf-ace-oauth-authz-38=3A_=28with_COMMENT=29?=
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2021 06:31:26 -0000

Hello Éric,

Thank you for your review. Sorry for the long waiting time.

Version -39 addresses your comments.
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39

Regards,

Ludwig

> -----Original Message-----
> From: Éric Vyncke via Datatracker <noreply@ietf.org>
> Sent: den 22 mars 2021 15:56
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-ace-oauth-authz@ietf.org; ace-chairs@ietf.org; ace@ietf.org
> Subject: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-ace-oauth-
> authz-38: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ace-oauth-authz-38: 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-ace-oauth-authz/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. I have really appreciated the
> informative and concise section 3 "overview". The flow and the explanations
> are really superb: if only all published RFC could have this level of quality ;-)
> 
> While I appreciate that the document shepherd was the past Jim Schaad, I
> find it weird to read a shepherd's review is for the -21 revision while the
> balloted revision is -38 as I usually rely on those write-ups to get an idea
> about the WG consensus... Anyway I am trusting the responsible AD for this
> I-D.
> 
> Side note: due to lack of time, I have skipped the security and IANA
> considerations sections as I trust the responsible AD.
> 
> Please find below some non-blocking COMMENT points (but replies would
> be appreciated), and some nits.
> 
> Last very minor/cosmetic comment about this document as well to the oAuth
> terminology: using "refresh tokens" sounds weird to me, I would have
> preferred "permanent tokens" or "long-term tokens", but, I am afraid that
> the train has left the station for many years ;-) And the same applies for
> "introspection"
> that usually is done internally and does not require a third party as in oAuth
> (but this is another train, which has also left the station...).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 3 --
> Should references/expansions be added for "HTTP/2, MQTT, BLE and QUIC"
> ?
> 
> -- Section 3.1 --
> Suggest to review the order of the definitions, notably popping up
> "introspection" as it is used by most of the other terms.
> 
> -- Section 4 --
> Mostly cosmetic, any reason why figure 1 is so far away from its mention in
> §1 ?
> 
> In "ensure that its content cannot be modified, and if needed, that the
> content is confidentiality protected", I wonder why the confidentiality is only
> optional ? As far as I understand it, the possession of an access token grants
> access to a ressource, so, it should be protected against sniffing. What did I
> miss ?
> 
> In "If the AS successfully processes the request from the client" may look
> ambiguous because processing correctly (per protocol) an invalid credential is
> also "successfully processed". Suggest to mention something about "positive
> authentication" ;)
> 
> -- Section 5 --
> As a non-English native speaker, I cannot see the verb in the second
> proposition in "For IoT, it cannot be assumed that the client and RS are part
> of a common key infrastructure, so the AS provisions credentials or
> associated information to allow mutual authentication.". While I obviously
> understand the meaning, could it be rephrased ?
> 
> -- Section 5.1.1 --
> Could the word "unprotected" be better defined in "received on an
> unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack
> of trust.
> 
> -- Section 5.1.2 --
> I must admit that I have failed to understand the semantic of "audience"...
> Can you either explain its meaning or provide a reference ?
> 
> -- Section 5.5 --
> In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g."
> ?
> 
> -- Section 5.6 --
> s/the semantics described below MUST be/the semantics described in this
> section MUST be/ ?
> 
> In "The default name of this endpoint in an url-path is '/token'" should
> "SHOULD" normative language be used ?
> 
> -- Section 5.6.4.1 --
> In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I
> failed to spot them in RFC 6749.
> 
> -- Section 5.7.2 --
> It is a little unclear to me which profile must be used as 'profile' is optionnial?
> Should a default or any profile be used ?
> 
> -- Section 5.8.1 --
> Suggest to use the BCP14 "SHOULD" in the text "The default name of this
> endpoint in an url-path is '/authz-info'"
> 
> -- Section 10.2 --
> Is RFC 7049 really an informative reference as CBOR appears as the default
> encoding ?
> 
> == NITS ==
> 
> s/application layer protocol/application-layer protocol/ ?
> 
> Should multi-words message names (e.g.,  AS Request Creation Hints) be
> enclosed by quotes ?
> 
> -- Section 2 --
> Please introduce "authz-info" before first use.
> 
> -- Section 3.1 --
> "PoP" is expanded twice in this section ;-)
> 
> "CBOR encoding (CWT) " the "CWT" acronym does not match the expansion
> :-)
> 
> -- Section 4 --
> 
> Sometimes "Client" is used and sometimes "client" is used...
> 
> s/reference to a specific credential/reference to a specific access credential/
> ?
> 
> -- Section 5.1.2 --
> Can you introduce to "kid" acronym ? It too me a while to understand that it
> is
> (probably) key-id... :-)
> 
> Unsure whether "nonce: h'e0a156bb3f'," is the usual IETF way to introduce
> an hexadecimal number.
> 
> typo in "5.8.4.  Key Expriation" :-)
> 
>