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

Daniel Migault <mglt.ietf@gmail.com> Fri, 16 April 2021 13:02 UTC

Return-Path: <mglt.ietf@gmail.com>
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 0B6AD3A250E; Fri, 16 Apr 2021 06:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jZvQ6ASTQLsl; Fri, 16 Apr 2021 06:02:43 -0700 (PDT)
Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 346083A24FE; Fri, 16 Apr 2021 06:02:43 -0700 (PDT)
Received: by mail-qv1-xf2f.google.com with SMTP id h15so3543634qvu.4; Fri, 16 Apr 2021 06:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+vvHKJmSiiGAQzLhrfvaQxfIaUEBkLz5G+LLcjHAAF4=; b=OV9VVNhltaETvGxx6M9Lsan1GyAv5/INYppEk7zS5DtUQS9HMlNrRzPJkrh3OOrVrY eyToKn+PyJsGERPwpXTHZPtJzHfIIUz7HtCgCJMad72fYlQc4jF8qczHywQu613nJYNg sotI3rT7mtf/4jZeKYf3ZwvyqH7LyW6pf62yqJcyPntRzhSLs0LQ7kPPBf7X3d/b2EGJ 9I07Tz02edSu99oBbWdTCgFDiIP4MgGGXmvG226Xms5jGwgO8qLwnz8oUzNidOZ+B/1y nUjUC0keJWtV5cJG33bx0yfA7WvClDgiGFO0dEvi1OdCRqN8IBUn7jYeOwtZYkMDZSNB h7kA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+vvHKJmSiiGAQzLhrfvaQxfIaUEBkLz5G+LLcjHAAF4=; b=GtVEhcV4c9eAzMFKwv91L96oyCQPY4UhxjVm6wTWbhwpU0s3pqfIbGUpKO1OmBNx2d GNLrhQbep+LNGa38cIiy/cZDMO71OnTSL1DYcRFXVHLyS1MknEPcT5nMCBy6Q1uGTdH0 W8te4aZYf/H1GlBYldi+l4YY1RbTjAFoa95WucA3RaW3nx0FZBM44b7aAM2cjl1rVJ5k 5NbsufZFZ5dj4ZWfoOI6pI/ClcQOv/0s98SnR4mXkQjuEE8SHhePAOh1l9WAnNR3StFf F/xMjK3HOtWpVYXhDDfQL1SCBnefLY6JndZDiNH/sRPb1PMCMRAlmWt3xOzxm07o6MFX /cWg==
X-Gm-Message-State: AOAM533Jb7EizR63Ud52p8lgmpyPab5+UrpEAsb+6r3Iqr1M1z8+xfqt JEk6sVkYwbHKwSw+L4WDD12ra0kB5y1igagrXIKsYIku
X-Google-Smtp-Source: ABdhPJxbJvzdr92KxOUxS19dKWSMTqvekHUVaW24yPhduSfSIht4aP8C3ViX9F8Rc4o0rV6wHynCak5T7M1Yne0Ub5M=
X-Received: by 2002:a05:6214:252d:: with SMTP id gg13mr8171341qvb.24.1618578160889; Fri, 16 Apr 2021 06:02:40 -0700 (PDT)
MIME-Version: 1.0
References: <161642497935.28459.6337296577160925255@ietfa.amsl.com> <17c975cd75bb4449a401c799672b1a6a@combitech.se> <313C317C-BD3A-4875-8695-B1245C55E029@cisco.com>
In-Reply-To: <313C317C-BD3A-4875-8695-B1245C55E029@cisco.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 16 Apr 2021 09:02:29 -0400
Message-ID: <CADZyTk=SdkKkSrM45rxPj_DXR=mVdqwLogif2reEuxNQa-2vyQ@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
Cc: Seitz Ludwig <ludwig.seitz@combitech.se>, The IESG <iesg@ietf.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005232b205c0169821"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/EH92cJskQGnNJoNvyrAL4FYmSNI>
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 13:02:54 -0000

Thanks Ludwig and Hannes for addressing the comments.

Yours,
Daniel

On Fri, Apr 16, 2021 at 6:46 AM Eric Vyncke (evyncke) <evyncke=
40cisco.com@dmarc.ietf.org> wrote:

> Ludwig,
>
> No problem for a delayed reply, the most important is to keep the Internet
> improving __
>
> Thank you for addressing my comments on this nice document.
>
> Regards
>
> -éric
>
>
> -----Original Message-----
> From: Seitz Ludwig <ludwig.seitz@combitech.se>
> Date: Friday, 16 April 2021 at 08:31
> To: Eric Vyncke <evyncke@cisco.com>om>, The IESG <iesg@ietf.org>
> Cc: "draft-ietf-ace-oauth-authz@ietf.org" <
> draft-ietf-ace-oauth-authz@ietf.org>gt;, "ace-chairs@ietf.org" <
> ace-chairs@ietf.org>gt;, "ace@ietf.org" <ace@ietf.org>
> Subject: RE: [EXTERNAL] Éric Vyncke's No Objection on
> draft-ietf-ace-oauth-authz-38: (with COMMENT)
>
>     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" :-)
>     >
>     >
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson