Skip to content

fix(apigw): pre-authorized OID4VCI credential flow#429

Draft
kushaldas wants to merge 1 commit into
mainfrom
fix/pre-authorized_oid4vci
Draft

fix(apigw): pre-authorized OID4VCI credential flow#429
kushaldas wants to merge 1 commit into
mainfrom
fix/pre-authorized_oid4vci

Conversation

@kushaldas

Copy link
Copy Markdown
Member

The credential endpoint rejected every pre-authorized issuance because the token-response credential_identifiers were never usable downstream, and the standalone OIDC-RP offer demanded a registry identifier it could not resolve.

  • handlers_oauth.go (Token): persist the generated credential_identifiers onto the authorization context via AuthContext.Update. They were only added to the response copy and never stored, so CredentialRequest.Validate could never find them ("credential_identifier ... not found in Token Response authorization_details").
  • pkg/openid4vci/credential.go (ResolveCredentialFormat): map credential_identifier back to its credential_configuration_id through the authorization_details, then resolve the format from issuer metadata. It previously looked the random UUID up directly as a config key ("could not resolve credential_identifier ...").
  • handlers_issuer.go: pass authContext.AuthorizationDetails to ResolveCredentialFormat.
  • handlers_oidcrp.go (standalone offer): set DataSource = assertion so the registry identifier is best-effort; the flow already stores the trusted IdP claims as the document, so an unmapped subject no longer fails with "no identifier in auth context".

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes the pre-authorized OID4VCI issuance flow in APIGW by ensuring credential_identifiers from the token response are persisted and can be resolved downstream, and by relaxing identifier requirements for assertion-based standalone OIDC-RP offers.

Changes:

  • Persist generated credential_identifiers to the cached authorization context in the token endpoint.
  • Resolve credential_identifier back to credential_configuration_id via token-response authorization_details before determining credential format.
  • Mark standalone OIDC-RP offers as assertion-based (DataSource=assertion) so registry identifier resolution is best-effort.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File Description
pkg/openid4vci/credential.go Updates credential format resolution to map opaque credential_identifier via authorization_details.
internal/apigw/apiv1/handlers_oauth.go Persists generated credential_identifiers onto the authorization context for later validation.
internal/apigw/apiv1/handlers_issuer.go Passes authorization details into format resolution.
internal/apigw/apiv1/handlers_oidcrp.go Sets standalone OIDC-RP auth context DataSource to assertion for best-effort identifier resolution.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread pkg/openid4vci/credential.go Outdated
Comment thread internal/apigw/apiv1/handlers_issuer.go Outdated
Comment thread internal/apigw/apiv1/handlers_oidcrp.go Outdated
Comment thread pkg/openid4vci/credential.go
The credential endpoint rejected every pre-authorized issuance because
the token-response credential_identifiers were never usable downstream,
and the standalone OIDC-RP offer demanded a registry identifier it could
not resolve.

- handlers_oauth.go (Token): persist the generated
  credential_identifiers onto the authorization context via
  AuthContext.Update. They were only added to the response copy and
  never stored, so CredentialRequest.Validate could never find them
  ("credential_identifier ... not found in Token Response
  authorization_details").
- pkg/openid4vci/credential.go (ResolveCredentialFormat): map
  credential_identifier back to its credential_configuration_id through
  the authorization_details, then resolve the format from issuer
  metadata. It previously looked the random UUID up directly as a config
  key ("could not resolve credential_identifier ..."). The new
  authDetails parameter is variadic so existing single-arg callers still
  compile.
- handlers_issuer.go: pass authContext.AuthorizationDetails to
  ResolveCredentialFormat.
- handlers_oidcrp.go (standalone offer): set DataSource = assertion so
  the registry identifier is best-effort; the flow already stores the
  trusted IdP claims as the document, so a subject without an identity
  mapping no longer fails with "no identifier in auth context".
- credential_test.go: cover the credential_identifier ->
  authorization_details mapping.
@sonarqubecloud

sonarqubecloud Bot commented Jun 3, 2026

Copy link
Copy Markdown

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Comment on lines +258 to +266
for _, ad := range authDetails {
if ad.CredentialConfigurationID != "" && slices.Contains(ad.CredentialIdentifiers, req.CredentialIdentifier) {
if metadata.CredentialConfigurationsSupported != nil {
if config, ok := metadata.CredentialConfigurationsSupported[ad.CredentialConfigurationID]; ok {
return config.Format, nil
}
}
return "", fmt.Errorf("unknown credential_configuration_id %q mapped from credential_identifier %q", ad.CredentialConfigurationID, req.CredentialIdentifier)
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants