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

[Seitz Ludwig <[e-mail]>]

Hello Zahed,

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

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

Regards,

Ludwig Seitz

> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <[e-mail]>
> Sent: den 24 mars 2021 02:27
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] Zaheduzzaman Sarker's No Objection on draft-ietf-ace-
> oauth-authz-38: (with COMMENT)
> 
> Zaheduzzaman Sarker 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:
> ----------------------------------------------------------------------
> 
> Thanks for working on this document. I found the overview section very
> helpful to setup the knowledge required to absorb the rest of the document.
> 
> I have following observations and/or nits, hopefully this will improve this
> document -
> 
> * Section 1:
>      For web
>      applications on constrained nodes, this specification RECOMMENDS the
>      use of the Constrained Application Protocol (CoAP) [RFC7252] as
>      replacement for HTTP.
> 
>   I can't parse the normative text "RECOMMENDS " :-). I believe if normative
>   text is used here then "RECOMMEND" or "RECOMMENDED" should be
> used. By the
>   way, there are more occurrence of "RECOMMENDS " in this document. The
> same
>   comment applied for those occurrences .
> 
> * Section 2 : I would suggest to drop "we use" from the beginning of last two
> paragraphs in this section and write those paraphaphs in passive form to
> harmonize with rest of the section.
> 
> * Section 3.1 :
>       Introspection is a method for a resource server to query the
>       authorization server for the active state and content of a
>       received access token.  This is particularly useful in those cases
>       where the authorization decisions are very dynamic and/or where
>       the received access token itself is an opaque reference rather
>       than a self-contained token.  More information about introspection
>       in OAuth 2.0 can be found in [RFC7662].
> 
>    I got gradually introduced in this document that potentially the client can
>    also use the method to query for more information (Section 5.9) via RS. I
>    think it will be helpful if this is described early that RS and client both
>    can use the introspection offered by AS.
> 
> * Section 4 : Figure 1
> 
>   The use of (optional) here is a bit confusing. The (optional) tag in (B)
>   means it is optional to include refresh token. For (D) and (E) the meaning of
>   (optional) is completely different. The response to the Introspection
> Request
>   is not optional, is it?.. but that interaction between AS and RS is optional.
>   It might be good to separate the use of "optional" in this figure / or amend
>   the figure in a different way to avoid such confusion.
> 
> * Section 5.2 :
> 
>       The request has been received on an unprotected channel.
> 
>   The definition of "unprotected" would be appropriated here. does this refer
>   to secure communication channel?
> 
> * Section 5.10.1. :
>    Typo : s/Section Section / Section
> 
>