From 56c8b9f88484d37e85fc633e685dafd84a44458c Mon Sep 17 00:00:00 2001 From: Ryan Richard Date: Fri, 29 Apr 2022 12:48:03 -0700 Subject: [PATCH] Add recommendations to dynamic client proposal --- proposals/1125_dynamic-supervisor-oidc-clients/README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/1125_dynamic-supervisor-oidc-clients/README.md b/proposals/1125_dynamic-supervisor-oidc-clients/README.md index 3f842b3f..f65546d4 100644 --- a/proposals/1125_dynamic-supervisor-oidc-clients/README.md +++ b/proposals/1125_dynamic-supervisor-oidc-clients/README.md @@ -478,6 +478,9 @@ desired. ## Open Questions - Which of the options presented above should we choose? Are there other options to consider? + - The author of this propsal doc would like to recommend that we choose: + - "Option 1: Providing client secrets already hashed", because of the tradeoffs of advantages and disadvantages discussed above. And also because client secrets should be decided by admins (see paragraph about that above). + - And "Option 1: Explicitly associate specific clients with issuers", because it sets us up nicely for the upcoming multiple IDP feature. However, if the team does not have an appitite for doing this now, then we could choose "Option 2: Implicitly associate all clients with all issuers" for now and then reconsider when we implement the upcoming multiple IDPs feature. The security concerns raised above with Option 2 are especially important with multiple IDP support. - Should we make the initial ID token from an authorization flow more inert? (See the audience confusion section above for more details.)