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> 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> 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> > wrote: > >> >> >> > On 10 Jan 2020, at 17:22, Dick Hardt <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
