Can the keys in the document at the jwks_uri indicate what they are for? Either by adding other top-level properties next to "keys" or by specifying a property on a key itself? At least that way implementations that expect just one value of jwks_uri wouldn't have to change.
Aaron On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <dick.ha...@gmail.com> wrote: > 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 >> <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 > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
