Hi Nat, Thank you for the updates. Please let me know when you publish a new version. I'll start last call after the new year. inline.
On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakimura <sakim...@gmail.com> wrote: > Hi > > Sorry to have taken so long to respond -- too much travel. > I hope you are able to rest a bit! > > My responses inline. > > On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > >> Hello, >> >> I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to >> be a nice addition to help with security. Thanks for your work on it. >> >> I only have a few comments. >> >> The first is just about some wording that is awkward in the TLS section. >> >> What's there now: >> >> Client implementations supporting the Request Object URI method MUST >> support TLS as recommended in Recommendations for Secure Use of >> Transport Layer Security (TLS) and Datagram Transport Layer Security >> (DTLS) [RFC7525]. >> >> How about: >> >> Client implementations supporting the Request Object URI method MUST >> support TLS following Recommendations for Secure Use of >> Transport Layer Security (TLS) and Datagram Transport Layer Security >> (DTLS) [RFC7525]. >> >> Not a major change and just editorial, so take it or leave it. >> > > Accepted as presented in my personal copy. > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13 > > >> >> 2. In section 10, the introduction sentence leaves me wondering where the >> additional attacks against OAuth 2.0 should also have a pointer in this >> sentence: >> >> In addition to the all the security considerations discussed in OAuth >> 2.0 [RFC6819], the following security considerations should be taken >> into account. >> >> >> > An IETF document about them has not been adopted yet. Shall I just add a > sentence or two describing the threats that each sub-sections are dealing > with? Or shall I point to the research papers that I was reading? (Some of > them are not freely available though.) > Any document that describes them will likely be an 'updates' to the OAuth spec, so we should be okay. Is the WG likely to adopt a draft soon? If so, we could wait to start IETF last call. > >> 3. Nit: in first line of 10.4: >> >> Although this specification does not require them, researchs >> >> s/researchs/researchers/ >> > > In fact, I meant either "research" or "researches" as I was not pointing > to persons but rather the work done by them. > I fixed it as "research" in my personal copy. > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83d0c0c36 > > >> 4. I'm sure you'll be asked about the following: >> >> ISO/IEC 29100 >> [ISO29100] is a freely accessible International Standard and its >> Privacy Principles are good to follow. >> >> What about the IETF privacy considerations for protocols, RFC6973, were >> they also considered? I think you are covering what's needed, but no >> mention of it and favoring an ISO standard seems odd., using both is fine. >> > > Good point. ISO/IEC 29100 is a high level document so the coverage is > wider but does not get into concrete details where as RFC6973 gives more > concrete guidance. They complement each other. I have added a paragraph > about RFC6873 in my personal copy. > > See: https://bitbucket.org/Nat/oauth-jwsreq/commits/9030e1be5cac > > I think you've covered the important privacy considerations from 6973, so the statement added on it should make that clear so the reader knows you've done the work for them already. Please let me know when the update has been posted. Thank you, Kathleen > >> Thank you. >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
