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

For new extensions, giving the key uri a new name would seem to work the
same as we have different names for different endpoints.

The cow is out of the barn for current work though.
ᐧ

On Fri, Jan 10, 2020 at 1:22 PM Richard Backman, Annabelle <
richanna@amazon.com> wrote:

> Having different JWKS URIs in the metadata document for different purposes
> would address the issue, but I’m not sure off-hand if we can clearly
> delineate purposes in a robust way without making it too complicated. So it
> may be correct for the working group to accept the situation for what it is.
>
>
>
> However, if we do that then we need to stop pretending that “use different
> keys” is a viable option. That tool needs to be tossed out of the toolbox,
> because our specifications do not allow implementers to do that in a
> meaningful way. The fact that we’ve used that argument despite this
> limitation demonstrates that this is a non-obvious result of the trust
> model we’ve adopted. If we stick with that model, we need to be more
> conscious of this issue in our future work. Some documents will need
> Security Considerations that draw attention to it, others may need more
> attention. We also need to recognize that we will be ruling out certain
> types of deployments, and certain use cases.
>
>
>
> –
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *Dick Hardt <dick.hardt@gmail.com>
> *Date: *Friday, January 10, 2020 at 11:00 AM
> *To: *Neil Madden <neil.madden@forgerock.com>
> *Cc: *Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>, Mike
> Jones <Michael.Jones@microsoft.com>, "Richard Backman, Annabelle" <
> richanna@amazon.com>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE:
> Cryptographic hygiene and the limits of jwks_uri
>
>
>
> To restate my previous point, we may not be able to change what is
> currently specified and deployed, but we can for future extensions such as
> RAR and PAR.
>
>
>
> To paraphrase Annabelle, this ship may have already sailed.
>
>
>
> On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> The metadata document is declarative, and can easily be yet another
> separate role in the AS.
>
>
>
> In large organizations, different people are empowered different roles, so
> the team owning the metadata document could be different from the team
> generating ID tokens, and different from the team generating JWTs.
>
>
>
>
>
> On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <neil.madden@forgerock.com>
> wrote:
>
> The problem with specifying a property on the key itself is that a
> microservice might lie about what it’s keys are for. I think you either
> need separate documents or some separate metadata mapping uses to key ids.
>
>
>
> — Neil
>
>
>
> On 10 Jan 2020, at 18:19, Aaron Parecki <aaron@parecki.com> wrote:
>
> !
>
> Can the keys in the document at the jwks_uri indicate what they are for?
> Either by adding other top-level properties next to "keys" or by specifying
> a property on a key itself? At least that way implementations that expect
> just one value of jwks_uri wouldn't have to change.
>
>
>
> Aaron
>
>
>
>
>
>
>
> On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Yes. Thanks for clarifying.
>
> ᐧ
>
>
>
> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
> You mean additional JWKS URIs, for example?
>
>
>
> Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com
> <dick.hardt@gmail.com>>:
>
> Perhaps I am misunderstanding what Annabelle was getting at, but having
> more than one key in the metadata document would solve the the issue. IE,
> extensions would define their own key instead of using the same one.
>
>
>
> The metadata document itself was an extension.
>
>
>
>
>
> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>
>
> > Am 10.01.2020 um 18:23 schrieb Dick Hardt <dick.hardt@gmail.com>:
> >
> > As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
> Provider, and the access token is being defined. These extensions have
> assumed all of this functionality is a monolith.
> >
> > I'm not suggesting that we MUST make changes to existing extensions, but
> design future extensions so that an implementation can separate duties if
> desired.
>
> How do you envision this to work? As you said, OAuth 2.0 is built on the
> assumption the AS is (at least logically) a monolith. All extension were
> built on that underlying assumption. I don’t see how an arbitrary extension
> can relax that assumption and still be compatible with the rest (just
> revisit the discussion re PAR and keys).
>
> I think we should accept this design assumption, in the same way we should
> accept form encoding as request format instead of JSON, for OAuth 2.0
> extensions.
>
> OAuth 3.0 could explicitely be developed with different architectures in
> mind.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> ----
>
> Aaron Parecki
>
> aaronparecki.com
>
> @aaronpk <http://twitter.com/aaronpk>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>