I would rather see extensions define a key ID than a new key set URI. Otherwise what’s the point of having more than one key in the set, with unique identifiers?
It would’ve been nice if JWK could’ve agreed on a URL-based addressing format for individual keys within the set, but that ship’s sailed. — Justin > On Jan 10, 2020, at 9:34 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > > I was not saying that there was anything special about keys, nor that we > needed to change OAuth. > > While using one key and controlling where it us used via access control > works, it is not ideal. > > OAuth could have had just one endpoint, and done access control for different > roles -- but it did not. We enabled flexibility by separating the > authorization endpoint and the token endpoint. The dynamic client > registration extension defined a new endpoint, the registration endpoint. > > I don't think we can change what has been deployed today -- but NEW > extensions that use keys for new purposes SHOULD define their own URI. > ᐧ > > On Fri, Jan 10, 2020 at 11:31 AM Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > Sure, but we know how to run resilient services. My point is that there’s > nothing particularly special about cryptographic keys: if you want to control > how they are used there is a whole range of normal access control methods you > can apply to them without needing to change anything in OAuth. > > Neil > >> On 10 Jan 2020, at 18:50, Dick Hardt <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> wrote: >> >> >> There are many other factors to resiliency than multiple instances. >> >> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <neil.mad...@forgerock.com >> <mailto:neil.mad...@forgerock.com>> wrote: >> >> >> > On 10 Jan 2020, at 17:22, Dick Hardt <dick.ha...@gmail.com >> > <mailto:dick.ha...@gmail.com>> wrote: >> [...] >> > >> > As to the suggestion of using a JWT-decryption-microservice, another goal >> > would be increased resiliency of the components. If the >> > JWT-decryption-microservice is unavailable, the whole system is >> > unavailable. If there are separate keys, then a failure in one component >> > does not fail the entire system. >> >> Well you can run more than one instance - it’s a completely stateless >> service. You can also run a separate instance (or set of instances) per key >> if you like. >> >> Neil
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
