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 protected]> Date: Friday, 16 April 2021 at 08:31 To: Eric Vyncke <[email protected]>, The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> 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 <[email protected]> > Sent: den 22 mars 2021 15:56 > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/ace
