Hi Roman!
Thank you very much for the review! We have incorporated your changes in the
newly submitted v-18
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but
you can also see the specific changes in the github commits:
https://github.com/ace-wg/ace-oscore-profile/commit/d64f5563d5be185cd7dcb6b8972dce33ae31c9c2
https://github.com/ace-wg/ace-oscore-profile/commit/8ad0db81cb391742887d5e1cae2cf33b0702836f
https://github.com/ace-wg/ace-oscore-profile/commit/a8caabb2ae5588a5923ac569a2fe85262031ed0c
Answers inline.
Thanks again,
Francesca
On 23/03/2021, 04:28, "Roman Danyliw via Datatracker" <nore...@ietf.org> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-ace-oscore-profile-17: Discuss
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-oscore-profile/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
(A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz],
the
name of the parameter in the C-to-AS communication is “ace_profile” (not
“profile”). The “ace_profile” parameter is mistakenly referenced as
“profile”
in the following place:
(a) Section 3.2.
The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "profile" parameter with the value
"coap_oscore" in the access token response
FP: Good catch! Fixed
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Kathleen Moriarty for the SECDIR review.
** In addition to the normative text noted in the DISCUSS, the examples in
Figure 4 and Figure 7 also have the same typo (but that doesn’t rise to a
DISCUSS)
FP: Indeed, fixed.
** Section 7. Per “Developers should avoid using multiple access tokens
for a
same client”, is there a reason not to use a normative SHOULD here? The
DTLS
profile has nearly the identical words and uses a normative SHOULD?
Likewise should “This profile recommends that the that RS maintains a single
access token for each client” be “This profile RECOMMENDS”?
FP: Right, now using BCP14 SHOULD and RECOMMENDS as you suggest.
** Editorial nits
Section 3.2. Typo. s/The applications needs/The application needs/
FP: Fixed.
Section 3.2. Typo. s/parameeter/parameter/
FP: Fixed.
Section 4. Typo. s/Note that the RS and client authenticates/Note that the
RS
and client authenticate/
FP: Fixed.
Section 4.1. Typo. s/The client may also chose/The client may also choose/
FP: Fixed.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
