Thanks Ludwig and Hannes for addressing the comments. Yours, Daniel
On Fri, Apr 16, 2021 at 6:46 AM Eric Vyncke (evyncke) <evyncke= [email protected]> 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 <[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 > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
