Yes. Thanks for clarifying. ᐧ On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt < tors...@lodderstedt.net> wrote:
> You mean additional JWKS URIs, for example? > > Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.ha...@gmail.com>: > > > 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
