Wallet initiated OID4VC authorization code flow fails with Keycloak 26.5.0 #45198

sberyozkin · 2026-01-06T23:30:31Z

sberyozkin
Jan 6, 2026

I'm testing a wallet initiated flow with 26.5.0:

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-3.4

and I get

[2026-01-06 23:17:24] ERROR: Credential issuance failed for PostQuantumCryptographyPhD. Response: {
  "error": "UNKNOWN_CREDENTIAL_IDENTIFIER",
  "error_description": "No credential offer state for credential id: PostQuantumCryptographyPhD"
}

which can't exist for a wallet initiated flow, and it is a problem for my demo, I'll have to stay at 26.4.7 for now...

The wallet initiated flow does not involve a credential offer flow.

For example, OID4VP presentation request goes to the Wallet that itself initiates a credential acquisition via the authorization code flow. Or Wallet is already aware of some well known credential types - see point 1.a at https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-3.4.

@mposolda Hi Marek, can you clarify please what is happening, perhaps I need to add something else to the authorization code flow request ?

Answered by Awambeng

Jan 7, 2026

@sberyozkin Thanks for reporting this.

In 26.5.0, the credential endpoint only accepts a credential_identifier that was generated by Keycloak and returned in the token’s authorization_details.

If the request includes a different or hard-coded identifier (for example, PostQuantumCryptographyPhD), the server returns UNKNOWN_CREDENTIAL_IDENTIFIER because there is no offer state associated with that ID.

Could you please check the token response you receive in the wallet-initiated flow and confirm the value of:

authorization_details[0].credential_identifiers[0]

That value should be used in the credential request.

Alternatively, if your flow does not rely on server-generated identifiers, you c…

View full answer

sberyozkin · 2026-01-07T00:08:25Z

sberyozkin
Jan 7, 2026
Author

Might be a false alarm, will double check tomorrow, apologies in advance if it proves the case

0 replies

Awambeng · 2026-01-07T08:24:38Z

Awambeng
Jan 7, 2026

@sberyozkin Thanks for reporting this.

In 26.5.0, the credential endpoint only accepts a credential_identifier that was generated by Keycloak and returned in the token’s authorization_details.

If the request includes a different or hard-coded identifier (for example, PostQuantumCryptographyPhD), the server returns UNKNOWN_CREDENTIAL_IDENTIFIER because there is no offer state associated with that ID.

Could you please check the token response you receive in the wallet-initiated flow and confirm the value of:

authorization_details[0].credential_identifiers[0]

That value should be used in the credential request.

Alternatively, if your flow does not rely on server-generated identifiers, you can send credential_configuration_id instead and omit credential_identifier. In that case, the endpoint will resolve the configuration directly.

If you can share the credential request payload and the token response, I’m happy to help verify further.

0 replies

sberyozkin · 2026-01-07T11:20:33Z

sberyozkin
Jan 7, 2026
Author

Thanks @Awambeng for having a look at this query,

Supplying authorization_details[0].credential_identifiers[0] fixed it, thanks a million, and sorry for a false alarm

1 reply

Awambeng Jan 7, 2026

Thanks for confirming @sberyozkin.
Glad to hear the issue is resolved and thanks for reporting back.

tdiesler · 2026-01-07T11:42:25Z

tdiesler
Jan 7, 2026

Yes, the use of credential_id instead of credential_configuration_id is currently under debate. If credential_id refers to a specific vc instance that the issuer created at a given point in time (e.g. when it made the offer), then that vc instance must be returned from the credential request. IMHO, it makes sense that the Issuer makes an offer as a snapshot of the current attribute configuration - as attribute values may change in a way that could effect the issuer's choice to make the offer.

Currently, the holder can always request a vc by configuration id or scope, without having received an offer

0 replies

Awambeng · 2026-01-07T12:09:01Z

Awambeng
Jan 7, 2026

Thanks @tdiesler, that makes sense.
We treat credential_identifier as an issuer-created offer snapshot, so it must come from the token’s authorization_details.
For wallet-initiated flows without an offer, credential_configuration_id (or scope) is the correct approach.
Appreciate the clarification on the design intent.

3 replies

sberyozkin Jan 7, 2026
Author

@Awambeng Hi,

For wallet-initiated flows without an offer, credential_configuration_id (or scope) is the correct approach.

So then, why does Keycloak return authorization_details[0].credential_identifiers[0] ? In my demo, in this particular case, no credential offer endpoint is called, the demo flow starts from the verifier and the wallet initiates a VC acquisition via an authorization code flow.

FYI, the redirect URL to Keycloak contains both scope and authorization_details, I guess this is what impacting it ?

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-3.3.4 mentions credential_configuration_id only in context of the scope option, when the token response does not return authorization_details, is what Keycloak doing too ?

I.e, does Keycloak make a decision that an offer was made based on whether authorization_details is present in the authorization code flow URL or not ?

This is just to understand it better, I'm totally OK with submitting credential_identifier taken from authorization_details[0].credential_identifiers[0], I guess our code will just check if authorization_details[0].credential_identifiers[0] is available - use it, otherwise fallback to the credential_configuration_id as I can imagine different issuers may be approaching it differently

Awambeng Jan 8, 2026

@Awambeng Hi,

For wallet-initiated flows without an offer, credential_configuration_id (or scope) is the correct approach.

So then, why does Keycloak return authorization_details[0].credential_identifiers[0] ? In my demo, in this particular case, no credential offer endpoint is called, the demo flow starts from the verifier and the wallet initiates a VC acquisition via an authorization code flow.

@sberyozkin Great questions.

Keycloak generates credential_identifiers whenever authorization_details is present in the authorization request, even if no explicit offer endpoint is called. In this case, Keycloak treats it as an implicit offer derived from the authorization_details parameter.

FYI, the redirect URL to Keycloak contains both scope and authorization_details, I guess this is what impacting it ?

Yes — it’s specifically the presence of authorization_details that drives this behavior.
If authorization_details is present, Keycloak follows the authorization-details flow and returns credential_identifiers.
scope alone would not trigger this path.

https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-3.3.4 mentions credential_configuration_id only in context of the scope option, when the token response does not return authorization_details, is what Keycloak doing too ?

Exactly. If authorization_details is not sent in the authorization request, the processor does not run, no credential_identifiers are created, and the token response does not include authorization_details.
In that case, the credential endpoint follows the credential_configuration_id (or scope) branch.

This is just to understand it better, I'm totally OK with submitting credential_identifier taken from authorization_details[0].credential_identifiers[0], I guess our code will just check if authorization_details[0].credential_identifiers[0] is available - use it, otherwise fallback to the credential_configuration_id as I can imagine different issuers may be approaching it differently

That approach makes sense.
Checking for authorization_details[0].credential_identifiers[0] first and falling back to credential_configuration_id should work well and stay compatible with different issuer implementations.

sberyozkin Jan 8, 2026
Author

Thanks @Awambeng for a very patient and great clarification, cheers

Wallet initiated OID4VC authorization code flow fails with Keycloak 26.5.0 #45198

Uh oh!

Uh oh!

sberyozkin Jan 6, 2026

Replies: 5 comments · 4 replies

Uh oh!

sberyozkin Jan 7, 2026 Author

Uh oh!

Awambeng Jan 7, 2026

Uh oh!

sberyozkin Jan 7, 2026 Author

Uh oh!

Awambeng Jan 7, 2026

Uh oh!

Uh oh!

tdiesler Jan 7, 2026

Uh oh!

Awambeng Jan 7, 2026

Uh oh!

Uh oh!

sberyozkin Jan 7, 2026 Author

Uh oh!

Awambeng Jan 8, 2026

Uh oh!

sberyozkin Jan 8, 2026 Author

sberyozkin
Jan 6, 2026

Replies: 5 comments 4 replies

sberyozkin
Jan 7, 2026
Author

Awambeng
Jan 7, 2026

sberyozkin
Jan 7, 2026
Author

tdiesler
Jan 7, 2026

Awambeng
Jan 7, 2026

sberyozkin Jan 7, 2026
Author

sberyozkin Jan 8, 2026
Author