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

From: Seitz Ludwig <[email-masked]>
Date: Fri, 16 Apr 2021 06:31:04 +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 <[email-masked]>
> Sent: den 22 mars 2021 15:56
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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" :-)
> 
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 16 Apr 2021 10:45:55 +0000

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 <[email-masked]>
Date: Friday, 16 April 2021 at 08:31
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-ace-oauth-authz-38: (with COMMENT)

    Hello Éric,

    Regards,

    Ludwig

---

From: Daniel Migault <[email-masked]>
Date: Fri, 16 Apr 2021 09:02:29 -0400

Thanks Ludwig and Hannes for addressing the comments.

Yours,
Daniel

On Fri, Apr 16, 2021 at 6:46 AM Eric Vyncke (evyncke) <evyncke=
[email-masked]> wrote:

> Cc: "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> Subject: RE: [EXTERNAL] Éric Vyncke's No Objection on
> draft-ietf-ace-oauth-authz-38: (with COMMENT)
>
>     Hello Éric,
>
>     > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson