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

[Daniel Migault <[e-mail]>]

Thanks Ludwig and Hannes for addressing the comments.

Yours,
Daniel

On Fri, Apr 16, 2021 at 6:46 AM Eric Vyncke (evyncke) <evyncke=
[e-mail]> 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 <[e-mail]>
> Date: Friday, 16 April 2021 at 08:31
> To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
> Cc: "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> 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 <[e-mail]>
>     > Sent: den 22 mars 2021 15:56
>     > To: The IESG <[e-mail]>
>     > Cc: [e-mail]; [e-mail];
> [e-mail]
>     > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>


-- 
Daniel Migault
Ericsson