Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be
fine to include additional keys that are used for something other than
access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a
decent extension mechanism.

On Mon, Jan 13, 2020 at 6:26 PM Justin Richer <jricher@mit.edu> wrote:

> 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.hardt@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.madden@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.hardt@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.madden@forgerock.com>
>> wrote:
>>
>>>
>>>
>>> > On 10 Jan 2020, at 17:22, Dick Hardt <dick.hardt@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
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>