Rephrasing Annabelle's description to highlight the issue: The AS says "here are the keys to use to verify all of the tokens that *we* have signed"
Separating duties in a large system is good cryptographic hygiene, IE, one component signs ID Tokens, another signs access tokens. On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> wrote: > This could be nice, but it’s solving a different problem. The issue I’m > drawing attention to is about how an AS indicates that a given key is > valid. That’s what the jwks_uri AS metadata property is for, and it does a > great job. The problem is that it does not allow enough granularity. > Currently all an AS can do is say “here are the keys to use to verify stuff > I signed.” It can’t say “here are the keys to use to verify ID Tokens, and > here is a different set of keys to use to verify access tokens.” > > — > Annabelle Backman > AWS Identity > > > On Jan 28, 2020, at 10:51 PM, Manger, James < > james.h.man...@team.telstra.com> wrote: > > > > > >> > >>> 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. > > > > Using the fragment on a JWKS URL to indicate the key id would be good. > > Then a single URL by itself can identify a specific key. > > > > https://example.com/keys.jwks#2011-04-29 > > > > This would have worked particularly well if a JWKS was a JSON object > with key-ids as the member names, instead of an array. That is presumably > too late to fix. But defining the fragment format for > application/jwk-set+json to be a kid value should be possible. > > > > If you put multiple keys with the same key-id in a JWKS you are asking > for trouble -- just call that a non-interoperable corner for people to > avoid. > > > > -- > > James Manger > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
