Description
The OCI resource repository (resource_repository.go#L272-L287) uses different key names than the component version repository path:

// oci/repository/resource/resource_repository.go — uses snake_case
credentials["refresh_token"] // ← snake_case
credentials["access_token"] // ← snake_case

// oci/credentials/docker_config.go — uses camelCase
CredentialKeyRefreshToken = "refreshToken" // ← camelCase
CredentialKeyAccessToken = "accessToken" // ← camelCase
Docker config can produce tokens. The Docker config.json supports identitytoken and registrytoken fields, and credential helpers (ECR, GCR, Azure ACR, osxkeychain) can return them. ORAS maps these to auth.Credential.RefreshToken / AccessToken, and ResolveV1DockerConfigCredentials() writes them as accessToken/refreshToken (camelCase) into the map.

The two OCI consumer paths diverge:

Component version repository (provider.go:145) uses CredentialFunc() from docker_config.go → reads accessToken/refreshToken (camelCase) — matches Docker config output
Resource repository (resource_repository.go:253) uses its own clientCredentials() → reads access_token/refresh_token (snake_case) — does NOT match Docker config output

Open topics

• should we support both ways of providing keys in this case for compatibility

Done Criteria

• Unify keys
• Keep or drop both key versions
• Code has been reviewed by other team members
• Analysis of existing tests (Unit and Integration)
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review