Retrieving a credential via an issuance flow fails when the issuer URL contains a path

[jer0622]

Hi,

Retrieving a credential via an issuance flow (authorization code or pre-authorized) does not work when the URL of the "credential_issuer" (found in the "credential_offer" object) contains a path.

• Issuance URL ok : https://issuer.example.com
• Issuance URL not ok : https://issuer.example.com/anypath

If the url is "https://issuer.example.com/anypath", the wallet makes a request to the endpoint "https://issuer.example.com/anypath/.well-known/openid-credential-issuer", but nothing happens after that. Whereas the "openid-credential-issuer" file is the same file used by an issuer without a path.

[jer0622]

In addition, the URL with a path is authorised in accordance with section 11.2.1. of the OID4VCI draft 13 protocol: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-issuer-identifie

[vafeini]

Hi @jer0622,

Spec mentions in section 10.2.2 that the metadata of the issuer are resolved by appending the /.well-known/openid-credential-issuer path segment to the issuer's identifier. Based on that the library is performing the following validation after resolving the metadata of the issuer:

It validates that the credential_identifier attribute of the metadata json (defined here) is equal to the url used to fetch the metadata (of course without the /.well-known/openid-credential-issuer path segment)

My guess is that in your case when you are serving the metadata json from the url with the path segment (https://issuer.example.com/anypath), the value of 'credential_identifier' attribute does not match that url.

Kind Regards

[babisRoutis]

Dear @jer0622

Is this issue still open or can be closed?

[jer0622]

Hello @vafeini , thank you for your reply. I finally managed to complete the issuance process with my issuer which contains a path. As you mentioned, it was indeed the ‘credential_issuer’ parameter in the metadata that had the wrong value.

However, I noticed something strange in the requests made by the wallet. Let's say my issuer is http://localhost/test/path, the wallet requests are :

• GET /test/path/.well-known/openid-credential-issuer
• GET /.well-known/openid-configuration/test/path
• GET /test/path/.well-known/openid-configuration

So it's the second request that's strange because it seems to be out of order.

But the issuance process still works, so I close the issue.

Kind Regards

[babisRoutis]

Hello @vafeini , thank you for your reply. I finally managed to complete the issuance process with my issuer which contains a path. As you mentioned, it was indeed the ‘credential_issuer’ parameter in the metadata that had the wrong value.

However, I noticed something strange in the requests made by the wallet. Let's say my issuer is http://localhost/test/path, the wallet requests are :

* GET /test/path/.well-known/openid-credential-issuer

* GET /.well-known/openid-configuration/test/path

* GET /test/path/.well-known/openid-configuration

So it's the second request that's strange because it seems to be out of order.

But the issuance process still works, so I close the issue.

Kind Regards

Dear @jer0622

During the resolution of client issuer metadata, library will also try to resolve the metadata of the authorization or OIDC server that protects the issuer. The 2nd and 3d GET requests from your case are part of the later (authorization server metadata resolution).

Please check https://github.com/eu-digital-identity-wallet/eudi-lib-jvm-openid4vci-kt/issues/224#issuecomment-2124863853 where some examples are provided for the URL via which the library will try to obtain the authorization or OIDC server metadata.