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 <[email protected]> > Sent: den 24 mars 2021 02:27 > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected] > 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 > > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
