For new extensions, giving the key uri a new name would seem to work the same as we have different names for different endpoints.
The cow is out of the barn for current work though. ᐧ On Fri, Jan 10, 2020 at 1:22 PM Richard Backman, Annabelle < richa...@amazon.com> wrote: > Having different JWKS URIs in the metadata document for different purposes > would address the issue, but I’m not sure off-hand if we can clearly > delineate purposes in a robust way without making it too complicated. So it > may be correct for the working group to accept the situation for what it is. > > > > However, if we do that then we need to stop pretending that “use different > keys” is a viable option. That tool needs to be tossed out of the toolbox, > because our specifications do not allow implementers to do that in a > meaningful way. The fact that we’ve used that argument despite this > limitation demonstrates that this is a non-obvious result of the trust > model we’ve adopted. If we stick with that model, we need to be more > conscious of this issue in our future work. Some documents will need > Security Considerations that draw attention to it, others may need more > attention. We also need to recognize that we will be ruling out certain > types of deployments, and certain use cases. > > > > – > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Dick Hardt <dick.ha...@gmail.com> > *Date: *Friday, January 10, 2020 at 11:00 AM > *To: *Neil Madden <neil.mad...@forgerock.com> > *Cc: *Aaron Parecki <aa...@parecki.com>, oauth <oauth@ietf.org>, Mike > Jones <michael.jo...@microsoft.com>, "Richard Backman, Annabelle" < > richa...@amazon.com> > *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: > Cryptographic hygiene and the limits of jwks_uri > > > > To restate my previous point, we may not be able to change what is > currently specified and deployed, but we can for future extensions such as > RAR and PAR. > > > > To paraphrase Annabelle, this ship may have already sailed. > > > > On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt <dick.ha...@gmail.com> wrote: > > 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
