The changes are meant to be backwards compatible with the current behaviour: if the project is rebuilt and redeployed as-is, everything should work as it did until now.
The new behaviour is driven by two environment variables that can be set at runtime: CONTROLLER_API_KEY and OIDC_JWKS_URI`.
If CONTROLLER_API_KEY is set, both the /issue-credential and /api/agentcb will expect the x-api-key header to be set and provide the value of CONTROLLER_API_KEY.
If OIDC_JWKS_URI is set, only the /issue-credential endpoint will be protected and the Authorization header with a value of Bearer mytoken will be required: the controller will check that the token was signed by the authority providing the jwks specified by OIDC_JWKS_URI, and reject the request if the validation fails.
If both CONTROLLER_API_KEY and OIDC_JWKS_URI are set, requests to /api/agentcb will require the x-api-key header while requests to /issue-credential will accept either the x-api-key header or the Authorization header (providing one of them will be enough).
The changes are meant to be backwards compatible with the current behaviour: if the project is rebuilt and redeployed as-is, everything should work as it did until now.
The new behaviour is driven by two environment variables that can be set at runtime:
CONTROLLER_API_KEYand OIDC_JWKS_URI`.If
CONTROLLER_API_KEYis set, both the/issue-credentialand/api/agentcbwill expect thex-api-keyheader to be set and provide the value ofCONTROLLER_API_KEY.If
OIDC_JWKS_URIis set, only the/issue-credentialendpoint will be protected and theAuthorizationheader with a value ofBearer mytokenwill be required: the controller will check that the token was signed by the authority providing the jwks specified byOIDC_JWKS_URI, and reject the request if the validation fails.If both
CONTROLLER_API_KEYandOIDC_JWKS_URIare set, requests to/api/agentcbwill require thex-api-keyheader while requests to/issue-credentialwill accept either thex-api-keyheader or theAuthorizationheader (providing one of them will be enough).