proposal for client context profiles

[paulswartz]

Here's what I was thinking:

External API

{ok, #oidcc_client_context{}} = oidcc_client_context:from_configuration_worker(
  Worker,
  <<"client_id">>,
  <<"client_secret">>,
  #{
    profiles => [fapi2]
  }).

Internal interface

• A new key is added to the oidcc_client_context record, client_opts
• The profiles is key mapped by oidcc_client_context into combination of client_opts (such as trusted_audiences as discussed in feat: Demonstrating Proof of Posession (DPoP) #315 ) and updates to the provider_configuration (enforcing S256 PKCE, removing less-secure signing/encryption algorithms)
• Items for client_opts can also be provided as opts in from_configuration_worker/4.
• The internal oidcc_* modules look at the client_opts rather than directly at profile keys. This allows profiles to share options, without needing the internals to be updated for each new profile.

[maennchen]

The difficulty I see with this approach is that we’re starting to mix function options with the client context, which only had one purpose so far.

Why would we have trusted_audiences, but not preferred_auth_methods in the client context?

I see an argument where we treat profiles differently from all the other options and have it solely in the client context.

[paulswartz]

Maybe trusted_audiences comes in as an opt for retrieve_token, but the ClientContext has something like only_trusted_audiences = true?

%% ClientContext looks like:
%% #oidcc_client_context{
%%   provider_configuration = #oidcc_provider_configuration{},
%%.  ...
%%   client_opts = #oidcc_client_context_opts{
%%    require_pkce = true,   
%%    only_trusted_audiences = true,
%%    only_requested_scopes = true,
%%    ...
%%  }
%% }
{ok, #oidcc_token{}} = oidcc_token:retrieve_token(AuthCode, ClientContext, #{trusted_audiences => [<<"other-client">>]}

[maennchen]

If we go down this route, I would probably avoid having two options controlling the same thing and instead just merge client context options and the function options.

For example for trusted_audiences:

• default is :any
• FAPI2 default (via client context profiles) is []
• the user can always override the function options with whatever he desires

What I like about your approach with the profiles option for the context resolving to dedicated options is that we control the "profile content" in one place. What I don't really like is that we're configuring via the client context which was not supposed to contain configuration besides the credentials.

oidcc v1 offered a worker that served both as metadata & keys loader and also stored client credentials and config. I wanted to split the concerns so that we don't have a process doing everything at the same time.

With this proposal we're kind of moving back towards that direction and I'm asking myself if we're using the correct abstraction or if we should provide a client context worker variant where the user only needs to specify some name / pid to reference the context.

[paulswartz]

I think I see what you're saying. Something like this?

{ok, #oidcc_token{}} = oidcc_token:retrieve_token(AuthCode, ClientContext, #{profiles => [fapi2]})

where that's translated internally to:

{ok, #oidcc_token{}} = oidcc_token:retrieve_token(AuthCode, ClientContext, #{require_pkce => true, trusted_audiences => [], ...})

[maennchen]

@paulswartz Yes, exactly.

[maennchen]

Implemented in #317