On Wed, Apr 22, 2020 at 5:36 PM Dick Hardt <dick.ha...@gmail.com> wrote:
> Brian: many, many thanks for all the feedback! > You are welcome. I won't lie - it was not a quick exercise :) > > I did a quick skim of your comments, and will address the first and last > ones. > > On Tue, Apr 21, 2020 at 3:49 PM Brian Campbell <bcampbell= > 40pingidentity....@dmarc.ietf.org <40pingidentity....@dmarc.ietf..org>> > wrote: > >> Been working on this on and off for a while now (it's not exactly short >> at 80+ pages, various other priorities, etc.) but wanted to share my >> thoughts from an initial review of the OAuth 2.1 draft before the interim >> next week where it is on the agenda >> https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/. >> So for better or worse, here's that review: >> >> Abstract: >> "replaces and obsoletes the OAuth 2..0 Authorization Framework described >> in RFC 6749." >> I think "replaces" is probably unnecessary here and, to be pedantic, is >> arguably inaccurate because published RFCs don't ever go away or get >> replaced. >> > > I took this language from RFC 6749: > > This specification replaces and obsoletes the OAuth 1.0 protocol > described in RFC 5849. > > > And adapted it. > Well then, I guess there's precedent for it. To me, it doesn't seem quite right. But I won't argue further with precedent. Probably should also consider using the official "obsoletes" attribute >> marker too for 6749 https://tools.ietf..org/html/rfc7991#section-2.45.8 >> <https://tools..ietf.org/html/rfc7991#section-2.45.8> and probably also >> "updates"/"obsoletes" for others based on the scope of the rest of the >> document (not sure how this even works with a BCP or if you can or would >> want to update or obsolete a BCP) if this work proceeds. That scope could >> be better described in the abstract too as discussed somewhat in the thead >> https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/ >> and also the 1st paragraph of >> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12. >> What is and isn't in scope is another larger question that I"m not even >> sure how to ask. What's included vs. what's referenced? Should this doc be >> incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda >> antithetical to what a BCP is supposed to be but it's also a bit hard to >> tell how much was used. I mean, what happens if/when the BCP is updated? >> And that kinda begs the question of if it should also incorporate parts of >> or even replace the browser based apps draft? >> > > Our thinking was to include all the documents where the OAuth Security > Topics was obsoleting sections of documents so that it could stand on its > own, and roll up all the best practices. > > If there are new best practices for OAuth 2.1, then that would be a new > BCP.. > Okay, thanks for the explanation. I think that generally makes sense. I was thinking more about the other direction like what it would mean for OAuth 2.1 to update or obsolete the existing BCP 212. But maybe that's not even an issue. I guess that's a TBD circa page 68. There was talk about the device grant >> being in scope but I'm not seeing it (not saying it should or shouldn't be >> there but it was talked about). I dunno exactly but those are some scope >> questions that come to mind. >> Speaking of obsoleting, I do want to ensure that existing extensions and >> profiles of RFC 6749 that use legitimate extension points still present and >> unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm >> not sure how that should work in practice but want to be aware of it as/if >> this work progresses. >> > > Perhaps have a section in the document listing all existing documents that > work fine with 2.1? > I'm honestly not sure if anything is needed or not. But I do want to try and ensure that such a perception problem doesn't arise. Perhaps have a small section that says more or less what I'd said above - that existing extensions and profiles of RFC 6749 that use legitimate extension points still present and unchanged in OAuth 2.1 are still okay as they are now? And include a not-meant-to-be exhaustive list of such documents as examples thereof. > <snip> > > >> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#appendix-C >> "TBD" >> Given the potentially high visibility of an OAuth 2.1 effort, I think >> it'd be worthwhile to list organizational affiliations of individuals here >> in the acknowledgements along with their names. Something like what was >> done in the first part of >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06#appendix-A. >> This can help with visibility and justification of (sometimes not >> insignificant) time spent on the work by non-authors/editors. >> > > Sure. Are you ok with being added there? > Yes, thank you. That was sort of implicit in my suggestion but perhaps I should have been explicit. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
