The metadata document is declarative, and can easily be yet another separate role in the AS.
In large organizations, different people are empowered different roles, so the team owning the metadata document could be different from the team generating ID tokens, and different from the team generating JWTs. On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <neil.mad...@forgerock.com> wrote: > The problem with specifying a property on the key itself is that a > microservice might lie about what it’s keys are for. I think you either > need separate documents or some separate metadata mapping uses to key ids.. > > — Neil > > On 10 Jan 2020, at 18:19, Aaron Parecki <aa...@parecki.com> wrote: > > ! > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
