Hello Charlie, Thank you for the review, sorry for the tardive reply (things got a bit chaotic due to an affiliation change on my part). The -10 version here: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params addresses your comments given the additional explanations by Ben.
Please confirm if this satisfies your requested changes. Regards, Ludwig -----Original Message----- From: Benjamin Kaduk <ka...@mit.edu> Sent: den 17 december 2019 23:02 To: Charlie Kaufman <charliekauf...@outlook.com> Cc: sec...@ietf.org; i...@ietf.org; draft-ietf-ace-oauth-params....@ietf.org Subject: Re: Secdir review of draft-ietf-ace-oauth-params-06 Hi Charlie, Thanks for the review! On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document only exists because of a scheduling issue between the ACE and > OAUTH working groups. The ACE working group needed some additional OAUTH > extensions added more quickly that the OAUTH group could manage to do it. > This document is intended to only exist until the OAUTH group can make the > corresponding changes. As such, it really doesn't have security > considerations beyond those in the document it modifies. > > The security considerations section says (and I agree): > > This document is an extension to [I-D.ietf-ace-oauth-authz]. All security > considerations from that document apply here as well. > > Some acronyms that were not defined (but this might be OK in the > context of this being a modification to another document): AS, RS, > CoAP, cnf, CBOR, pop, CWT > > > A few typos / odd phrasing: > > Abstract: whishes -> wishes > Appendix A: possesion -> possession > > >From Section 2: > Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749] > definition, which is to denote resources such as token and introspection at > the AS and authz-info at the RS. > > Really? The term "endpoint" refers to tokens and authz-info data structures? > This seems unlikely. Not data structures, but (HTTP/CoAP) resources -- "things you can POST to". > Continuing in Section 2: > The CoAP [RFC7252] definition, which is "An entity participating in the CoAP > protocol" is not used in this specification. > > Why is a definition that does not apply relevant to this document? This document is at the intersection of two worlds: CoAP and OAuth. Both define "endpoint" but in contradictory ways. Since at least one has to lose, giving the reader a pretty explicit hint that they're wrong to use a given definition seems to have value. But maybe I'm in the rough; we'll see :) -Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
