Brian: many, many thanks for all the feedback! 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= [email protected]> 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. > Probably should also consider using the official "obsoletes" attribute > marker too for 6749 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.. > 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? <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?
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
