I don't think you are missing anything, George (except that, to be pedantic, `kid` is a header rather than a claim).
The question gave me pause, however, and makes me think that maybe the draft, with the aim of improved interoperability, should have some more explicit text about the use of the 'kid' header in a JWT AT and how it references the verification key in the content at the jwks_uri. On Wed, Mar 25, 2020 at 11:54 AM George Fletcher <gffletch= 40aol....@dmarc.ietf.org> wrote: > Can we not use the 'kid' claim to inform the RS as to which key is being > used? What am I missing? > > On 3/25/20 1:51 PM, Brian Campbell wrote: > > I think, even without that statement in the draft, that ASes already have > license to use different keys if they so choose. And maybe I'm not creative > enough but I can't think of what problematic assumptions RSes might make > that would prevented by it. So perhaps just removing that whole sentence, > "An authorization server MAY elect to use different keys to sign id_tokens > and JWT access tokens."? Just a thought anyway. > > On Wed, Mar 25, 2020 at 10:11 AM > <vittorio.bertocci=40auth0....@dmarc.ietf.org> wrote: > > > Thank you for the perspective- I guessed something similar (“there would > be no way for the RS to know what key is used for what"). > > As stated below, the intent wasn’t to prevent substitution/confusion, but > mostly to give ASes license to use different keys if they choose to (for > the reasons listed below, or any other reason they might have) and a > headsup to RSes so that they don’t make assumptions. > > > > *From:* Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> > <bcampbell=40pingidentity....@dmarc.ietf.org> > *Sent:* Wednesday, March 25, 2020 8:48 AM > *To:* Vittorio Bertocci <vittorio.berto...@auth0.com> > <vittorio.berto...@auth0.com> > *Cc:* Richard Backman, Annabelle <richa...@amazon.com> <richa...@amazon.com>; > oauth <oauth@ietf.org> > *Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth > 2.0 Access Tokens" > > > > I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's > comment was an assumption that signing ATs and ID Tokens with different > keys would be done to prevent token substitution/confusion. And there's not > really a practical way to achieve that with the mechanics of the jwks_uri... > > > > On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci > <vittorio.bertocci=40auth0....@dmarc.ietf.org> wrote: > > *>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with > different keys is to publish the keys in two different JWK sets. This only > way to do this today is by publishing separate OAuth 2.0 authorization > server metadata and OIDC Discovery metadata files, where the JWK set in the > former applies to access tokens and the JWK set in the latter applies to ID > Tokens.* > > Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they > all can be used for signing. What prevents the AS to use one key from that > list for IDtokens and another for ATs? Separate discovery docs shouldn’t be > necessary. Sure, there would be no way for the RS to know what key is used > for what- but similar mechanisms are already in place today for handling > signing key rotation: e.g. the discovery doc lists the current key and the > future key, but uses only the current- and the RS has no way of > distinguishing between the two. The situation here can be analogous, any > key in the discovery doc should be considered valid by the RS, and in fact > there’s no requirement about selecting specific keys in the validation > section. That doesn’t mean this is useless, an AS might elect to use > different keys for its own purposes (eg separation of concerns for > forensics, different strengths, different lifecycles, and so on). > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.... > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Brian Campbell Distinguished Engineer bcampb...@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image: LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter logo] <https://twitter.com/pingidentity> [image: facebook logo] <https://www.facebook.com/pingidentitypage> [image: youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image: Blog logo] <https://www.pingidentity.com/en/blog.html> <https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> <https://www.pingidentity.com/en/events/d/identify-2019.html> <https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-execsummary.pdf> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/events/e/rsa.html> <https://www.pingidentity.com/en/lp/e/enabling-work-from-home-with-MFA.html> *If you’re not a current customer, click here <https://www.pingidentity.com/en/lp/e/work-from-home-sso-mfa.html?utm_source=Email&utm_campaign=WF-COVID19-New-EMSIG> for a more relevant offer.* -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
