Perhaps I am misunderstanding what Annabelle was getting at, but having more than one key in the metadata document would solve the the issue. IE, extensions would define their own key instead of using the same one.
The metadata document itself was an extension. On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > > > Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.ha...@gmail.com>: > > > > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect > Provider, and the access token is being defined. These extensions have > assumed all of this functionality is a monolith. > > > > I'm not suggesting that we MUST make changes to existing extensions, but > design future extensions so that an implementation can separate duties if > desired. > > How do you envision this to work? As you said, OAuth 2.0 is built on the > assumption the AS is (at least logically) a monolith. All extension were > built on that underlying assumption. I don’t see how an arbitrary extension > can relax that assumption and still be compatible with the rest (just > revisit the discussion re PAR and keys). > > I think we should accept this design assumption, in the same way we should > accept form encoding as request format instead of JSON, for OAuth 2.0 > extensions. > > OAuth 3.0 could explicitely be developed with different architectures in > mind.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
