DIIP V4 Test Bed

[k00ij]

You can use this channel to post any questions or feedback related to the DIIP V4 Test Bed.
This open Test Bed is available for everybody. Initially focussing on personal and organizational wallet providers.
In the near future it will be extended with use case specific test cases.

To register your organization, your wallets and receive an account to login please send a mail to testbed@fides.community.

Access to the Test Bed: https://itb.ilabs.ai/

[eklaver]

Great initiative! I can see and start the test cases for the personal wallet, but I don't see it for the organisation wallet (Holder). Of course I can download the issuance request and give that to the organisation wallet, but it would be nice if there would be an input field to specify the credential offer endpoint of the org wallet.

[endimion]

hi @eklaver this is not a bad idea... is this usually a POST request to org wallets? As far as I know this part is not specified in the OIDC specs... is there some consensus around it in DIIP?

[eklaver]

Hi @endimion, this is a GET request to the credential offer endpoint of the wallet (the same as clicking a link, only automatic redirect). The openid-credential-offer:// is replaced by the credential offer endpoint of the wallet.

[eklaver]

The pre-authorized code flow doesn't return the REQUIRED pre-auhthorized code in the credential offer:

{
"credential_issuer": "https://itb.ilabs.ai/rfc-issuer",
"credential_configuration_ids": [
"VerifiablePortableDocumentA2SDJWT"
],
"grants": {
"authorization_code": {
"issuer_state": "99302244-0e0a-4c4f-b79e-2ae7f73d964e"
}
}
}

In the grants, it should include something like (besides the authorization_code):

"urn:ietf:params:oauth:grant-type:pre-authorized_code": {
"pre-authorized_code": "oaKazRN8I0IbtZ0C7JuMn5",
"tx_code": {
"length": 4,
"input_mode": "numeric",
"description": "Please provide the one-time code that was sent via e-mail"
}
}

[endimion]

@eklaver for which test case is this being generated so I can have a look please?

[eklaver]

@endimion, for instance at TC-000002

[endimion]

many thanks there was a typo and was triggering code flow instead.. should be fixed now..

[eklaver]

[like] Eelco Klaver reacted to your message:

…

________________________________ From: Nikos Triantafyllou ***@***.***> Sent: Monday, June 16, 2025 2:05:49 PM To: FIDEScommunity/DIIP ***@***.***> Cc: Eelco Klaver ***@***.***>; Mention ***@***.***> Subject: Re: [FIDEScommunity/DIIP] DIIP V4 Test Bed (Discussion #59) many thanks there was a typo and was triggering code flow instead.. should be fixed now.. Closing but if you find any issues please re-open @k00ij<https://github.com/k00ij> — Reply to this email directly, view it on GitHub<#59 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAELVVSYRDZSVG2AA4NNT3T3D3FL3AVCNFSM6AAAAAB7IEZWHCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNBYGQ4DCNI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[muisit]

A quick feedback message: I am trying to get a grip on what this platform actually does, for me as issuer builder as SURF. It seems that I can create an intermediate service that creates a QR code that can then be used by wallets to consume it. However, it is inconvenient to use QR codes. There are wallets that can consume links (same-device flows for example, or command-line-base wallets). It would be more convenient to have the intermediate service generate the credential offer and then have the ITB generate a qr code from that if that is required. Or perhaps create a set of tests that are not kicked off with a QR code, but directly with a credential offer.

[endimion]

can definetly start writting something up..

For now hope the following pics is helpful:

after clikcing the magnifying glass...

[endimion]

@muisit I might have mis-under stood your question...

If you want to integrate your issuer you can follow this approach: https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc100-interoperability-profile-towards-itb.md

where you can expose the an endpoint:

`Request:
curl -X 'GET'
'https://issuer-service.com/credentialIssuanceRequest?sessionId=123&credentialType=myCredential'
-H 'accept: application/json'

Response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"qr": "data:image/PNG;base64,iVBORw0KGgoAAAA...",
"deeplink":"issue-vp-uri",
"sessionId": "123"
}

Error Response:
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{
"status": "fail",
"reason": "credential type not supported",
"sessionId": "123"
}`

either qr code or deeplink is fine for integration

[muisit]

Thanks for your quick reply. Although I recognise the screenshots as coming from the itb, I have no idea at all where I could find this. Perhaps I am missing authorisation. The only thing I see is 3 systems (issuer, verifier, wallet), of which 2 have no conformance tests. The wallet gives me some tests, but no configuration options as far as I can see.

[muisit]

The document you link to does not mention a 'deeplink' attribute in the credentialIssuance service call. Nor does it mention where I can configure such a service in the ITB. Is there more documentation on the whole ITB setup for DIIPv4 apart from the document you linked to?

[endimion]

The no reference to the deeplink is a typo and will be corrected...

to add tests for your issuer/verifier (systems) you will need to expose the APIs described in https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc100-interoperability-profile-towards-itb.md

and then comunicate these endpoints with @k00ij or me and I will generate the test suite for your issuer/verifier inside the ITB...

You do not configure the ITB instance your self as this requires backend code modifications and not only test script generations

[lebedenko-ubique]

W3C VCDM-based Credentials

In DIIPv4 Credential Format it is described that:

Requirement: DIIP-compliant implementations MUST support W3C VCDM and more specifically Securing JSON-LD Verifiable Credentials with SD-JWT as specified in (VC-JOSE-COSE).

Currently in the Test Bed, W3C VCDM-based Credentials are issued and secured as described in OpenID4VCI, which does not align with the method specified in Securing JSON-LD Verifiable Credentials with SD-JWT.

What is the intended method?

[endimion]

Hey @lebedenko-ubique I beleive this is an oversight and will revert. The intended method should be as described in

Requirement: DIIP-compliant implementations MUST support W3C VCDM and more specifically Securing JSON-LD Verifiable Credentials with SD-JWT as specified in (VC-JOSE-COSE).

thanks for reporting will follow up once this is updated

[endimion]

hey a fix has been deployed please have a look

[ubamrein]

@endimion Hi, I'm answering on behalf of @lebedenko-ubique. Was trying to issue the credential (e.g. VerifiableIdCardJwtVc configuration id), currently the format is still jwt_vc_json, which I believe might be the wrong one. If I understand DIIPv4 correctly, it should use https://www.w3.org/TR/vc-jose-cose/#media-types which defines the format to be vc+sd-jwt.

Which brings me to another issue:
Alltough the metadata correctly identifies the used sd-jwt in Test case 000001 as dc+sd-jwt, the returned credential still uses vc+sd-jwt.

[endimion]

ah ok yes an oversight will revert in a bit and let you know

[endimion]

Hey @ubamrein cheers for posting! first point yes good catch forgot to update after the previous fix. Will deploy a fix with the rest of the changes today.

For the second great catch! it seem the lib adds the type if not expilictly set to vc+sd-jwt . will be fixed in the release today

[lebedenko-ubique]

Digital Credentials Query Language (DCQL)

In DIIPv4 Section 4.6 it is described that:

The presentation of claims from the Holder's Wallet to the Verifier is done along the OID4VP.

In OID4VP the Digital Credential Query Language (DCQL) is defined.

Currently in all Test Cases for Presentation (000006,000007,000008,000009) the dcql_query parameter looks as follows:

"dcql_query": {
    "credentials": [
        {
            // ...
            "claims": [
                {
                    "path": [
                        "$.given_name"
                    ]
                },
                {
                    "path": [
                        "$.family_name"
                    ]
                },
                {
                    "path": [
                        "$.birth_date"
                    ]
                },
                {
                    "path": [
                        "$.age_over_18"
                    ]
                },
                {
                    "path": [
                        "$.issuance_date"
                    ]
                },
                {
                    "path": [
                        "$.expiry_date"
                    ]
                },
                {
                    "path": [
                        "$.issuing_authority"
                    ]
                },
                {
                    "path": [
                        "$.issuing_country"
                    ]
                }
            ],
            // ...
        }
    ]
}

Note that the path in the claims object seems to be a JSONPath which does not align with Claim Path Pointer defined in OID4VP. Is this intended?

[endimion]

hey a fix has been deployed please have a look

[ubamrein]

Thanks this seems to work now :)

[ubamrein]

VP Response alg in JWK

In test case 00...6 the generated presentation request contains a JWK specifiying "alg" : "ECDH-ES+A256KW". As the key could be used with any of the supported key length for CEK, it should be avoided to add the specific CEK alg into the JWK, hence using ECDH-ES as the alg parameter.

Further, https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-encrypted-responses only specifies the encrypted_response_enc_values_supported value in the client_metadata. I think authorization_encryption_alg_values_supported is only supported for wallet metadata when using https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-request-uri-method-post

[endimion]

pushing a fix for this as well

[endimion]

fix deployed

[ubamrein]

Invalid JWE Response

When posting to the VP endpoint with an ECDH-ES+A256KW encrypted response, we receive 400: Invalid JWE-Response. I couldn't figure out on how to get more information about the error (e.g. ed17142a-32ca-4289-baa6-20ce869b2774).

I also tested with some other verifiers, and there the decryption seems to work (so at least the JWE seems to be correct).

[ubamrein]

Might be related:
When using direct_post we get:

Cannot read properties of undefined (reading 'input_descriptors')

Assuming the error message is correct, this would be wrong, as the presentation request contains a DCQL query, which defines the response format as in https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-response-parameters

[endimion]

deploying a fix for this. I do not ahve a wallet that supports this flow unfortunately to test.. if any public wallet impl is available that would be great. Else ping me once you have had a chance to test @ubamrein

[lebedenko-ubique]

This issue still persists. For tc000008 we are getting the following response:

{
  "error": "Cannot read properties of undefined (reading 'input_descriptors')"
}

Request:

key	value
vp_token	{"pid_credential":"eyJ0eXAiOiJkYytzZC1qd3QiLCJraWQiOiJhZWdlYW4jYXV0aGVudGljYXRpb24ta2V5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczovL2l0Yi5pbGFicy5haS9yZmMtaXNzdWVyIiwiaWF0IjoxNzU0OTAyNjY3LCJuYmYiOjE3NTQ5MDI2NjcsImV4cCI6MTc3MDgwMDI2NywidmN0IjoidXJuOmV1LmV1cm9wYS5lYy5ldWRpOnBpZDoxIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IkFwblhVM21yU3BJX0tLZkFmYXFNSjFEdE9EaGRWUlVoblFGQi1PSndLSDAiLCJ5IjoiTW1Pak1oNXpmMnlZMTlzQ2VMTGV0RUduXy14N3lTTmpsWG5SdEJJREpTRSJ9fSwiX3NkIjpbIktrMmotTVczVDNvdFgyRGt1dDVKYm9neHRDeEtENWJPQUNZUXh6eGE0WFEiLCJOSkJYVDczYXJEaGt5ZUpxMFlheHJEaTJzYXk4eXhUZEFEU2hFLTA1R2NjIiwiX04wM2xGd0Z6bFhMSFZJRXltRGdGRzlBYXZReGtkWGNPaFRmSnBzYUZ6QSIsIl9nS3R6XzhYbk5UZjJNNEJITUh6OEtaTUlkRlNTWjhaYndPUkllRUdCUVkiLCJfc1FrdGVuaW9veHJqTGg3enVtYXNPYVAyUDJqcDNCZFpWTVpSVzkyMWY0IiwiY1lqcmJhV1JkdEh3VlhuTFIyWFBOSzZHREFuSnFwamg1ZDdMc3FUNGR6RSIsImdzcmI1LUFPUXZqeGtmc3J2Qnh5dzF0Nk9sSTNuWW9fR1oyRDE5bDI5YkkiLCJxbHU1ZDJpQzdhbG5BUVlDd3BVMUpzLUVXV1dBaVRVYkFnUVFWdk9jc2RNIl0sIl9zZF9hbGciOiJzaGEtMjU2In0.klZfVp0tCZPaB0yilLfBL6LqCMfhPaM93IqBOFANYvF6voFqjAdodWptgJ2Dd9FeO-XbT29P7n7g7DZEvsLbvw~WyI2Mjc1NzM3NDAxNDQ2YTZhIiwiYWdlX292ZXJfMTgiLHRydWVd~WyI3MDY0OGQ3Y2Q4NDMyNjk0IiwiaXNzdWluZ19hdXRob3JpdHkiLCJVQWVnZWFuIFRlc3QgSXNzdWVyIl0~WyI4NzIwMmFiMDkzMDQ4ZDQzIiwiZmFtaWx5X25hbWUiLCJNYXRrYWxhaW5lbiJd~WyI5NGViYjhmNTU5ZGFkZmFiIiwiYmlydGhfZGF0ZSIsIjAxLjA3LjIwMDUiXQ~WyIwNzk1YTVkMzg0MGNkZDY5IiwiZ2l2ZW5fbmFtZSIsIkhhbm5hIl0~WyJhZTBhMGZlZTUyZDI1ZWY1IiwiaXNzdWFuY2VfZGF0ZSIsMTc1NDkwMjY2NzQyN10~WyJjZmI5NTdmYmMxYjU3M2UyIiwiaXNzdWluZ19jb3VudHJ5IiwiRmlubGFuZCJd~WyJlMDg0NDMyOTk2YmNlNjY5IiwiZXhwaXJ5X2RhdGUiLDE3ODY0Mzg2Njc0Mjdd~eyJ0eXAiOiJrYitqd3QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJkZWNlbnRyYWxpemVkX2lkZW50aWZpZXI6ZGlkOndlYjppdGIuaWxhYnMuYWk6cmZjLWlzc3VlciIsImlhdCI6MTc1NDkxNjMxMCwibm9uY2UiOiJiOGNiNDQ1ZjYxZmU3YTdjY2Q3M2JiMmU5YWRhZTk1ZCIsInNkX2hhc2giOiJBcnE4TW83WGJ2Q1hsNFhzazBMYS1FUEJkbGlVWXBJM3dZY3lmMmJRUDNvIn0.PhiRxhEwPU5Q87Byt4V7pzayr8o44NcQxIEc8g8iKw0PXO8buLFn7rLCmTcWAvFtqnsOxOywXAXNTI7NUPgL7Q"}
presentation_submission	{}
state	0c9bec7732eba98e275f948009a9272f

From my understanding, input_descriptors should not be read as the presentation uses DCQL.

[lebedenko-ubique]

EDIT: Seems to have been an issue on our side, can confirm that it works now.

[goIDmobility]

Inconsistent request URI method

The DIIP V4 Interop Profile explicitly mentions to support only the "get" method as a part of request_uri. However, we notice test case 9 "Test case 000009: VP did:web direct_post, post and sdjwt" tests the "post" method which is not part of the DIIP V4 profile.

OID4VP defines two values for the request_uri_method in the Authorization Request: get and post. DIIP requires support for only the get method.
Requirement: DIIP-compliant implementations MUST support the get value for the request_uri_method in the Authorization Request.

OID4VP Request: openid4vp://?request_uri=https://itb.ilabs.ai/rfc-issuer/did/VPrequest/104c363d-a124-4b17-a15d-50dc324a105b&**request_uri_method=post**&client_id=decentralized_identifier:did:web:itb.ilabs.ai:rfc-issuer

[endimion]

hey this is correct will delete the case for POST request uri... thanks for reporting this

[goIDmobility]

Thank you.

[goIDmobility]

@endimion Any reason why this test case is being added back to test bed, as the request URI method post is not part of DIIP v4?

[endimion]

sorry redployed the suite.. had forgotten to delete it from the code base.. will remove again.. thanks for reporting

[goIDmobility]

Thank you so much

[goIDmobility]

Need clarity on Test case 000001: VCI Authorization Code flow X.509 SD-JWT

Do you believe you could kindly confirm why the title of test case 000001 includes the word "X509" in the title and how this relates to the DIIP V4 Interop Profile? The reason I ask is because I was under the impression the DIIP V4 Profile will not use X509 certificates.

[ubamrein]

I also wanted to ask, since I thought it will feature openid-federation, but it seems that the testbed issuer does not offer the well-known "well-known" endpoint.

[endimion]

Hey, this is a typo in the name of the test case the actual test case uses did:web if I am not mistaken. Reverting...

[goIDmobility]

Authorization Request JWT Missing Required typ Value oauth-authz-req+jwt

According to the OID4VP Specification (draft-28), Section 6.3 and RFC9101, the typ header in a JWT-secured Authorization Request must be:
"typ": "oauth-authz-req+jwt"
However, the testbed currently sends:
"typ": "JWT"
Example from testbed request header:
{
"alg": "ES256",
"typ": "JWT",
"kid": "did:web:itb.ilabs.ai:rfc-issuer#keys-1"
}
This causes compliant wallets to reject the request, as they are mandated to not process JWTs that lack the correct typheader.
Expected Header Example:
{
"alg": "ES256",
"typ": "oauth-authz-req+jwt",
"x5c": [...optional...]
}

Whether this would be corrected ?

[endimion]

a fix should be deployed please have a loook

[goIDmobility]

Still I am seeing the typ as JWT in the request header with Test case 000008

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDp3ZWI6aXRiLmlsYWJzLmFpOnJmYy1pc3N1ZXIja2V5cy0xIn0.eyJyZXNwb25zZV90eXBlIjoidnBfdG9rZW4iLCJyZXNwb25zZV9tb2RlIjoiZGlyZWN0X3Bvc3QiLCJjbGllbnRfaWQiOiJkZWNlbnRyYWxpemVkX2lkZW50aWZpZXI6ZGlkOndlYjppdGIuaWxhYnMuYWk6cmZjLWlzc3VlciIsInJlc3BvbnNlX3VyaSI6Imh0dHBzOi8vaXRiLmlsYWJzLmFpL3JmYy1pc3N1ZXIvZGlyZWN0X3Bvc3QvNjM1ZDE0NTAtZTNiMi00MDJmLWJlNzEtYWMyOTVhZDZhOGRmIiwibm9uY2UiOiI4MmZmNWIxZDhlNTZkYjk3M2IzMTk3MTE4MzFlZjdmYyIsInN0YXRlIjoiNDJkOGI1ZWE0N2FkMTQ2MTlmMDMzYzYxZmMwMTA2OGEiLCJjbGllbnRfbWV0YWRhdGEiOnsiY2xpZW50X25hbWUiOiJVQWVnZWFuIEVXQyBWZXJpZmllciIsImxvZ29fdXJpIjoiaHR0cHM6Ly9zdHVkeWluZ3JlZWNlLmVkdS5nci93cC1jb250ZW50L3VwbG9hZHMvMjAyMy8wMy8yNS5wbmciLCJsb2NhdGlvbiI6IkdyZWVjZSIsImNvdmVyX3VyaSI6InN0cmluZyIsImRlc2NyaXB0aW9uIjoiRVdDIHBpbG90IGNhc2UgdmVyaWZpY2F0aW9uIiwidnBfZm9ybWF0c19zdXBwb3J0ZWQiOnsiand0X3ZjX2pzb24iOnsiYWxnX3ZhbHVlcyI6WyJFUzI1NiIsIkVTMzg0Il19LCJkYytzZC1qd3QiOnsic2Qtand0X2FsZ192YWx1ZXMiOlsiRVMyNTYiLCJFUzM4NCJdLCJrYi1qd3RfYWxnX3ZhbHVlcyI6WyJFUzI1NiIsIkVTMzg0Il19LCJtc29fbWRvYyI6eyJpc3N1ZXJhdXRoX2FsZ192YWx1ZXMiOlstNywtMzVdLCJkZXZpY2VhdXRoX2FsZ192YWx1ZXMiOlstNywtMzVdfX0sImp3a3MiOnsia2V5cyI6W3sia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJyVG1fdjRaYXdpYTRPNVZvd1FnZHVaT0dndEpEd0hrV0tQZU04SnlvUVJjIiwieSI6InFqRGVsYWRLNEhXU1Jhd3pPTWpHMEtIV1FWNjA5dkFFX0NZVE9HcTN0OXciLCJ1c2UiOiJlbmMiLCJraWQiOiJlbmMta2V5LTEiLCJhbGciOiJFQ0RILUVTK0EyNTZLVyJ9XX0sImVuY3J5cHRlZF9yZXNwb25zZV9lbmNfdmFsdWVzX3N1cHBvcnRlZCI6WyJBMTI4R0NNIiwiQTE5MkdDTSIsIkEyNTZHQ00iLCJBMTI4Q0JDLUhTMjU2IiwiQTE5MkNCQy1IUzM4NCIsIkEyNTZDQkMtSFM1MTIiXX0sImF1ZCI6Imh0dHBzOi8vc2VsZi1pc3N1ZWQubWUvdjIiLCJkY3FsX3F1ZXJ5Ijp7ImNyZWRlbnRpYWxzIjpbeyJpZCI6InBpZF9jcmVkZW50aWFsIiwiZm9ybWF0IjoiZGMrc2Qtand0IiwibWV0YSI6eyJ2Y3RfdmFsdWVzIjpbInVybjpldS5ldXJvcGEuZWMuZXVkaTpwaWQ6MSJdfSwiY2xhaW1zIjpbeyJwYXRoIjpbImdpdmVuX25hbWUiXX0seyJwYXRoIjpbImZhbWlseV9uYW1lIl19LHsicGF0aCI6WyJiaXJ0aF9kYXRlIl19LHsicGF0aCI6WyJhZ2Vfb3Zlcl8xOCJdfSx7InBhdGgiOlsiaXNzdWFuY2VfZGF0ZSJdfSx7InBhdGgiOlsiZXhwaXJ5X2RhdGUiXX0seyJwYXRoIjpbImlzc3VpbmdfYXV0aG9yaXR5Il19LHsicGF0aCI6WyJpc3N1aW5nX2NvdW50cnkiXX1dfV19LCJ2ZXJpZmllcl9hdHRlc3RhdGlvbnMiOlsiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbXRwWkNJNkltUnBaRHAzWldJNmFYUmlMbWxzWVdKekxtRnBPbkptWXkxcGMzTjFaWElqYTJWNWN5MHhJaXdpZEhsd0lqb2lhbmQwSW4wLmV5SnBjM01pT2lKa1pXTmxiblJ5WVd4cGVtVmtYMmxrWlc1MGFXWnBaWEk2Wkdsa09uZGxZanBwZEdJdWFXeGhZbk11WVdrNmNtWmpMV2x6YzNWbGNpSXNJbk4xWWlJNkltUmxZMlZ1ZEhKaGJHbDZaV1JmYVdSbGJuUnBabWxsY2pwa2FXUTZkMlZpT21sMFlpNXBiR0ZpY3k1aGFUcHlabU10YVhOemRXVnlJaXdpYVdGMElqb3hOelV6T0RrME5qYzFMQ0psZUhBaU9qRTNOVE00T1RneU56VXNJbUYwZEdWemRHRjBhVzl1SWpwN0luQnZiR2xqZVY5MWNta2lPaUpvZEhSd2N6b3ZMMmwwWWk1cGJHRmljeTVoYVM5eVptTXRhWE56ZFdWeUwzQnZiR2xqZVM1b2RHMXNJaXdpZEc5elgzVnlhU0k2SW1oMGRIQnpPaTh2YVhSaUxtbHNZV0p6TG1GcEwzSm1ZeTFwYzNOMVpYSXZkRzl6TG1oMGJXd2lMQ0pzYjJkdlgzVnlhU0k2SW1oMGRIQnpPaTh2YVhSaUxtbHNZV0p6TG1GcEwzSm1ZeTFwYzNOMVpYSXZiRzluYnk1d2JtY2lmWDAuVTN2VzAwRkg4SkFKd1lFejR2bFpSTW1kV24yTEVfZThVeVBmYzh2OVhDY1BKV3lxQnY0M0l3RzdIbjRqakk1cTN4dnlKYUxQNmhxaDdWNHd2WlU2Z1EiXX0.AMMoIuIU6tRUp6EACFHE-WSLJl7a_S3tzVv6HvRJzxJgFY2WMEABDgP9I4K-YaBTQ3Nor-6hdDmh8tE5KZuehg

[goIDmobility]

Observed the same for 6 and 7

[endimion]

should be fixed

[goIDmobility]

Thank you, this is now fixed

[goIDmobility]

Observed a data issue in the format for "vc+sd-jwt"

Observed a data issue in the issuance format. An unwanted space has been added in the front making it to appear as - "format":" vc+sd-jwt",

I believe, the space has to be removed. Could this be corrected?

[endimion]

reverted

[goIDmobility]

This is fine now. Thanks.

[goIDmobility]

Titles of VCI pre-authorization code flow test cases appear to be interchanged

The test case - "Test case 000002: VCI pre-authorization code flow - no PIN - sdjwt", it incorrectly prompts for a pin. Conversely, in the test case - "Test case 000003: VCI pre-authorization code flow - PIN - sdjwt", it does not ask for a pin where it is supposed to.

Is this a typo? Could you please confirm if this will be modified?

[endimion]

reverted

[goIDmobility]

This is now modified and looks fine. Thanks.

[goIDmobility]

Clarification required on VCI pre-authorization code flow - with PIN - sdjwt

I have a few questions regarding the pre-authorization code flow - with PIN. Test case ref:
[Test case 000002: VCI pre-authorization code flow - no PIN - sdjwt]

• In Pre-authorization code flow, there is a prompt to enter one time code. Does this relate to the OpenID4VCI "transaction code"? Could you please confirm?

• If this is indeed the transaction code, where does the user obtain this code? The prompt states that it will be sent via email. How does the email sending process work? Is the email sent to the account performing the test?

• Additionally, when we attempt to proceed with the flow by entering any random 4-digit values, we can move forward without receiving any error. Could you clarify how the random code is accepted without generating an error?

[endimion]

hey again

1. yes its usually refered to as a pin..
2. this is just an example. the requirement is to send it via a different channel

usually it is displayed in the issuers web page but other mechanisms might of course apply 3. it is out of scope for interoperability testing to ensure the user is properly authenticated. As a result the actual code used is not checed

for 2. and 3. of course this can be supported in the test bed (e.g. showing the pin as a different prompt... ) but in my opinion this is not necessary. However if there is a consensus such tests are needed please let me know

[goIDmobility]

Would it be possible to display the pin as a different prompt in the test bed to ensure the usage of transaction code has been validated and implemented correctly from the client side?

[endimion]

added checks for tx code and visual elements in IT UI

[goIDmobility]

Invalid Response mode on testing reject scenario

When testing the holder reject scenario,

As per the openid4vp draft 28 spec,

"If the Response URI has successfully processed the Authorization Response or Authorization Error Response, it MUST respond with an HTTP status code of 200 with Content-Type of application/json and a JSON object in the response body."

we are expecting http status code as 200, but we are getting error 400 and error desc as {"error":"No vp_token found in the request body."}

[muisit]

I changed my vp_token to not output a vp attribute, but instead put VerifiablePresentation in the root of the token. And I enveloppe encode the credential supplied (whoever thought this was a good idea...). It now looks like:

vp_token=%7B%22pid_credential%22%3A%5B%22eyJhbGciOiJFUzI1NiIsImtpZCI6IiMwIiwidHlwIjoidnArand0In0.eyJpc3MiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWRYTmxJam9pYzJsbklpd2lZV3huSWpvaVJWTXlOVFlpTENKNElqb2lUM3BTVmkxVmVVSmxXVEJpYzJKblZFSXpOV05HVERCZlkzQk1TME5YWWtwU0xWVmZYMFJmTTBKVWR5SXNJbmtpT2lKUFYxbDRZa3h6U3kxZlUwRkpNbWxQTjB0eU1YQnpNbWR3T1hoa2RIRlVVR1ZXTkVoTFdFeGhObkJuSW4wIiwiYXVkIjoiZGlkOndlYjppdGIuaWxhYnMuYWk6cmZjLWlzc3VlciIsIm5iZiI6MTc1ODAxNjczMywiaWF0IjoxNzU4MDE2NzMzLCJleHAiOjE3NTgwMTg1MzMsIm5vbmNlIjoiYTBlMmUxNDIzZWNjMGEwYmMwN2E5MTVkMTAwZDUxNWEiLCJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6WyJWZXJpZmlhYmxlUHJlc2VudGF0aW9uIl0sInZlcmlmaWFibGVDcmVkZW50aWFsIjpbeyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiXSwidHlwZSI6IkVudmVsb3BlZFZlcmlmaWFibGVDcmVkZW50aWFsIiwiaWQiOiJkYXRhOmFwcGxpY2F0aW9uL2RjK3NkLWp3dCxleUowZVhBaU9pSjJZeXR6WkMxcWQzUWlMQ0pyYVdRaU9pSmhaV2RsWVc0allYVjBhR1Z1ZEdsallYUnBiMjR0YTJWNUlpd2lZV3huSWpvaVJWTXlOVFlpZlEuZXlKcGMzTWlPaUpvZEhSd2N6b3ZMMlJ6Y3k1aFpXZGxZVzR1WjNJdmNtWmpMV2x6YzNWbGNpSXNJbWxoZENJNk1UYzFOakV4TmpJeU5pd2libUptSWpveE56VTJNVEUyTWpJMkxDSmxlSEFpT2pFM056SXdNVE00TWpZc0luWmpkQ0k2SW5WeWJqcGxkUzVsZFhKdmNHRXVaV011WlhWa2FUcHdhV1E2TVNJc0ltTnVaaUk2ZXlKcWQyc2lPbnNpYTNSNUlqb2lSVU1pTENKamNuWWlPaUpRTFRJMU5pSXNJbXRwWkNJNklqQXlNMkl6TkRVMVpqazBZemd4TnprNFpERmlZakZpT0RFek1EYzNaVFZqTVRSaVpETm1Oekk1TW1OaE1EazJObU01TkRkbE5UTm1abU16Wm1ZM01EVXpZeUlzSW5WelpTSTZJbk5wWnlJc0ltdGxlVjl2Y0hNaU9sc2lkbVZ5YVdaNUlsMHNJbUZzWnlJNklrVlRNalUySWl3aWVDSTZJazk2VWxZdFZYbENaVmt3WW5OaVoxUkNNelZqUmt3d1gyTndURXREVjJKS1VpMVZYMTlFWHpOQ1ZIY2lMQ0o1SWpvaVQxZFplR0pNYzBzdFgxTkJTVEpwVHpkTGNqRndjekpuY0RsNFpIUnhWRkJsVmpSSVMxaE1ZVFp3WnlKOWZTd2lYM05rSWpwYklqVkVTMjlzWDA1d1NYVmhiMVJsTm05clFYcGlZVE5WV25wb04yODBOMHBuVUUwM2NsbGFlV2xwWDNjaUxDSTJSWGRvVEZGeldHeDJjbGhyZHpkdWVsODNNbWx1ZVhsMk4xUkdabXBrZFhOVFMyODJORWw2UW5GRklpd2lVVGhDUzNNMlQxSllWSFIzTTBORFYwRnJaalZMTVhGUlFqQjRaalJyVkVFdGFWbFJNa2x6VDFGWWR5SXNJbHBzYmpSQ09XcHhWblJEV0ZkS01HaGZaM0ZZT0ZaNVRtaGZabXRVVkZoc2NHNUpkMjlNZFcwd2JtY2lMQ0pmVjNaTWJEZENjamxpVlZkbGJsUnJiMlF3YTBRMWExVjNSMDFxVHpWQmJXSnViQzFET0V4MmMwcEJJaXdpWkVvM2FYSmlRMDF3VFRCaFgwc3dlbGN4ZWxFMVRqbHJOVkpOTUZkdlIyVmhXalpxU2pJNWJ6VmpUU0lzSW00MFVVUjZURTkxUzJkblpIcFpWMmcwZUVkcWVVdDRYMWhPYzJ4eVlYbElTWEZEZVdkdFUxOXdiREFpTENKMlRVb3hRbkIyWmpCSlNrZHpjVlpHVjJkR1VWcHRXakJLYVc1SFptWnFMVWh1VFdvd2VIRnFaM28wSWwwc0lsOXpaRjloYkdjaU9pSnphR0V0TWpVMkluMC51QXFYX1NneUdLbWNDZTRoRkJkcWtzQlpZRm9mcWpROFQzSjRBVFU3ODNvSVZmNWcwZC1odVNkMkUyMjRYaEt0NFNtYk91VHNWdzhSdFdxVDFiMElmd35XeUl4TlRFMk9HWTRPRFl5T0RSbFpXVXpJaXdpWjJsMlpXNWZibUZ0WlNJc0lraGhibTVoSWwwfld5Sm1PV0ZrWmprd01qQmtaamN6WXpNd0lpd2labUZ0YVd4NVgyNWhiV1VpTENKTllYUnJZV3hoYVc1bGJpSmR-V3lJMFpqaGtPREV6WkRjNU5qQmtNVGRtSWl3aVltbHlkR2hmWkdGMFpTSXNJakF4TGpBM0xqSXdNRFVpWFF-V3lJNU9EYzNOekkwT1Rkak56RXpNakUzSWl3aVlXZGxYMjkyWlhKZk1UZ2lMSFJ5ZFdWZH5XeUpqTnpGaU5XRmpNak5sWTJZMk9EVmxJaXdpYVhOemRXRnVZMlZmWkdGMFpTSXNNVGMxTmpFeE5qSXlOall3TlYwfld5STVOR1JsTW1FeFpUSXlNakV4Wm1VNUlpd2laWGh3YVhKNVgyUmhkR1VpTERFM09EYzJOVEl5TWpZMk1EVmR-V3lJNFpqazVNMkZtTTJGak9Ua3hNemxtSWl3aWFYTnpkV2x1WjE5aGRYUm9iM0pwZEhraUxDSlZRV1ZuWldGdUlGUmxjM1FnU1hOemRXVnlJbDB-V3lJd1pUTTRZek15WVRSbU5tUmlNekU0SWl3aWFYTnpkV2x1WjE5amIzVnVkSEo1SWl3aVJtbHViR0Z1WkNKZH4ifV19.qD0Yw1Z6cBiE-Z0JkW4jaCkjlSIKOqDxiQrFccdKtx-8DlenOk7qf5-q8ypHAYOfxznrGQT3UeybqB4do4jSFw%22%5D%7D&state=511ece1dfb6818b46ca1e6ce8686422f

Still the same error though. But is this more akin to what you are referring to?

[ubamrein]

vp_token=%7B%22pid_credential%22%3A%22eyJ0eXAiOiJkYytzZC1qd3QiLCJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbmdpT2lJM2VXMUhhWEJyVEdReGIzaFNSMWxEU1dGME9EUlBjWHAxVUdaTU1GbHZUQzF5V1VGdlMzRlFhbmhySWl3aWVTSTZJa1ZLVEVRNFJHSTRPRXhRTW5Oa01raERiRlpyV25Ka2VHd3dlV2x3YlVkVlprdEdPRFZKWmxWVk5sRWlMQ0pqY25ZaU9pSlFMVEkxTmlKOSMwIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbmdpT2lJM2VXMUhhWEJyVEdReGIzaFNSMWxEU1dGME9EUlBjWHAxVUdaTU1GbHZUQzF5V1VGdlMzRlFhbmhySWl3aWVTSTZJa1ZLVEVRNFJHSTRPRXhRTW5Oa01raERiRlpyV25Ka2VHd3dlV2x3YlVkVlprdEdPRFZKWmxWVk5sRWlMQ0pqY25ZaU9pSlFMVEkxTmlKOSIsImlhdCI6MTc1ODAwNzM1NSwibmJmIjoxNzU4MDA3MzU1LCJleHAiOjE3NzM2NDU3NTUsInZjdCI6InVybjpldS5ldXJvcGEuZWMuZXVkaTpwaWQ6MSIsImNuZiI6eyJraWQiOiJkaWQ6andrOmV5SnJkSGtpT2lKRlF5SXNJbU55ZGlJNklsQXRNalUySWl3aWVDSTZJbkpsZDNOWmF5MVJNakJWVVdOUU1FUnhWakJvV1U5ME0wdFpOVEZUVUY5U00weGlZbTQzVEdKc1RFa2lMQ0o1SWpvaVZETTNTMnRPY2pkalNHWkJlSFZZVTBsSE5uaERURVoyUm14Uk1XZGhWRkF4TVRsb2JtMVlaVW80Y3lKOSMwIn0sInN0YXR1cyI6eyJzdGF0dXNfbGlzdCI6eyJ1cmkiOiJodHRwczovL2l0Yi5pbGFicy5haS9yZmMtaXNzdWVyL3N0YXR1cy1saXN0L2E5ZTFlMGE1LWFiZGEtNGI3My1iYzkxLWI0YzhhMDA4MzIyYyIsImlkeCI6NTd9fSwiX3NkIjpbIjJUamZoLTl3RWE1UWV4LXFLcENaS3dtMU9TbDZ2c21zMld3SEpseWh1aVkiLCIzNlo3QVpEdUR1R3JlZWs0MF9DZ3RzZ3JUcC1JZm9QdTJIUDJGdGtjS1hvIiwiV3RtenNITDRKWGpDT2NuXzJoMzBZdklNam9tSzJ1d1FEZGw3QU1OTy1qQSIsImVINVlJQ2tubHlwQ3pJMjZhaG81RlRIR3QxaEJJd3RKYlNZUzFuYkdIQnMiLCJtTHd4UWFDY2RzemJyekhESXF3SzQzdVI3TFM0V0Yxa0xCdUE5d1VMSndnIiwidzk3cHFkOW1BQ0Q4QVlqdkhIekU0aW1waXB4ZHpDeGhaUlR4MWVfUnJVZyIsInhMT0xncDB6YTFVMkNvRl91TGlwbUQzV3lVbkI1c0FTYzFWYkZCS3pqUTgiLCJ4bktUM3ZyTFNhcnk1djBCM3lkYTljVDBQRWhiTjdtc1RHWENxeGs4dXJrIl0sIl9zZF9hbGciOiJzaGEtMjU2In0.6fvLz86IKkbXSofVh8pXByStDD3RGd9kDNp0LHJG4-3_hu83DLnzVMdzHBqmwh2ENFqecxRIebr0tZ3EDsrQtA~WyI0ZjExOTRhOTgyN2QxNjQ0IiwiaXNzdWFuY2VfZGF0ZSIsMTc1ODAwNzM1NTA1NF0~WyI1MTY2NDVhODk3ZmQ2NGVlIiwiZXhwaXJ5X2RhdGUiLDE3ODk1NDMzNTUwNTRd~WyI2YWVjOTUzOGFkMzgyOWQ0IiwiYWdlX292ZXJfMTgiLHRydWVd~WyI2ZDRlYzcxYjYwY2RiYjVjIiwiZmFtaWx5X25hbWUiLCJNYXRrYWxhaW5lbiJd~WyI3MDhmMWMzOGYwYTQ5ZWE3IiwiaXNzdWluZ19hdXRob3JpdHkiLCJVQWVnZWFuIFRlc3QgSXNzdWVyIl0~WyIxMTM3YjVjOWU1MDY1NzUzIiwiaXNzdWluZ19jb3VudHJ5IiwiRmlubGFuZCJd~WyJhNjVkZjNmMzhmNzdiNWRmIiwiYmlydGhfZGF0ZSIsIjAxLjA3LjIwMDUiXQ~WyJkODU3ZmI2ZmNjYjU1MzQzIiwiZ2l2ZW5fbmFtZSIsIkhhbm5hIl0~eyJ0eXAiOiJrYitqd3QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJkZWNlbnRyYWxpemVkX2lkZW50aWZpZXI6ZGlkOndlYjppdGIuaWxhYnMuYWk6cmZjLWlzc3VlciIsImlhdCI6MTc1ODAxNzEyNywibm9uY2UiOiI1ZDc3OWFkNzRiMzNiMjEyMzA1ZTE0NDllMWYwNTRiOSIsInNkX2hhc2giOiJ3Z2NKQWZaNDhFRjJER3IzX3BHX1ljdVBVTUlwcF80cmNaZE5Jd09LbW1jIn0.hqNDbRuqszdBmnAGbwvpLq3hgXwOh_yRTECFjFyoIju_6cRGeGzbofm1-RJvSaKQ3YzQr8CooxkHKaiIOV-y4w%22%7D&state=744c142ccc2b7055d289b1b1dd330f7f

This is what is being accepted by the testbed (this is how it should be according to the draft-ietf-oauth-sd-jwt-vc-11 above)

EDIT:
Besides the point that I think the credential is revoked. @endimion do you check revocation during the VP flow in the test bed?

[endimion]

hey I think this mostly has to do with how a EnvelopedVerifiableCredential was handled. I added and am deploying a fix for it... (@ubamrein not at this test case... revocation is not checked... ). Please have a look and let me know... Also access to the wallet to be able to test my self would be great to help debug ;)

[muisit]

I am now passing:
vp_token=%7B%22pid_credential%22%3A%5B%22eyJ0eXAiOiJ2YytzZC1qd3QiLCJraWQiOiJhZWdlYW4jYXV0aGVudGljYXRpb24ta2V5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczovL2Rzcy5hZWdlYW4uZ3IvcmZjLWlzc3VlciIsImlhdCI6MTc1NjExNjIyNiwibmJmIjoxNzU2MTE2MjI2LCJleHAiOjE3NzIwMTM4MjYsInZjdCI6InVybjpldS5ldXJvcGEuZWMuZXVkaTpwaWQ6MSIsImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsImtpZCI6IjAyM2IzNDU1Zjk0YzgxNzk4ZDFiYjFiODEzMDc3ZTVjMTRiZDNmNzI5MmNhMDk2NmM5NDdlNTNmZmMzZmY3MDUzYyIsInVzZSI6InNpZyIsImtleV9vcHMiOlsidmVyaWZ5Il0sImFsZyI6IkVTMjU2IiwieCI6Ik96UlYtVXlCZVkwYnNiZ1RCMzVjRkwwX2NwTEtDV2JKUi1VX19EXzNCVHciLCJ5IjoiT1dZeGJMc0stX1NBSTJpTzdLcjFwczJncDl4ZHRxVFBlVjRIS1hMYTZwZyJ9fSwiX3NkIjpbIjVES29sX05wSXVhb1RlNm9rQXpiYTNVWnpoN280N0pnUE03cllaeWlpX3ciLCI2RXdoTFFzWGx2clhrdzduel83MmlueXl2N1RGZmpkdXNTS282NEl6QnFFIiwiUThCS3M2T1JYVHR3M0NDV0FrZjVLMXFRQjB4ZjRrVEEtaVlRMklzT1FYdyIsIlpsbjRCOWpxVnRDWFdKMGhfZ3FYOFZ5TmhfZmtUVFhscG5Jd29MdW0wbmciLCJfV3ZMbDdCcjliVVdlblRrb2Qwa0Q1a1V3R01qTzVBbWJubC1DOEx2c0pBIiwiZEo3aXJiQ01wTTBhX0swelcxelE1TjlrNVJNMFdvR2VhWjZqSjI5bzVjTSIsIm40UUR6TE91S2dnZHpZV2g0eEdqeUt4X1hOc2xyYXlISXFDeWdtU19wbDAiLCJ2TUoxQnB2ZjBJSkdzcVZGV2dGUVptWjBKaW5HZmZqLUhuTWoweHFqZ3o0Il0sIl9zZF9hbGciOiJzaGEtMjU2In0.uAqX_SgyGKmcCe4hFBdqksBZYFofqjQ8T3J4ATU783oIVf5g0d-huSd2E224XhKt4SmbOuTsVw8RtWqT1b0Ifw~WyIxNTE2OGY4ODYyODRlZWUzIiwiZ2l2ZW5fbmFtZSIsIkhhbm5hIl0~WyJmOWFkZjkwMjBkZjczYzMwIiwiZmFtaWx5X25hbWUiLCJNYXRrYWxhaW5lbiJd~WyI0ZjhkODEzZDc5NjBkMTdmIiwiYmlydGhfZGF0ZSIsIjAxLjA3LjIwMDUiXQ~WyI5ODc3NzI0OTdjNzEzMjE3IiwiYWdlX292ZXJfMTgiLHRydWVd~WyJjNzFiNWFjMjNlY2Y2ODVlIiwiaXNzdWFuY2VfZGF0ZSIsMTc1NjExNjIyNjYwNV0~WyI5NGRlMmExZTIyMjExZmU5IiwiZXhwaXJ5X2RhdGUiLDE3ODc2NTIyMjY2MDVd~WyI4Zjk5M2FmM2FjOTkxMzlmIiwiaXNzdWluZ19hdXRob3JpdHkiLCJVQWVnZWFuIFRlc3QgSXNzdWVyIl0~WyIwZTM4YzMyYTRmNmRiMzE4IiwiaXNzdWluZ19jb3VudHJ5IiwiRmlubGFuZCJd~eyJ0eXAiOiJrYitqd3QiLCJhbGciOiJFUzI1NiJ9.eyJpYXQiOjE3NTgwMzA0OTksImF1ZCI6ImRpZDp3ZWI6aXRiLmlsYWJzLmFpOnJmYy1pc3N1ZXIiLCJub25jZSI6ImM1ZTQ5MTlmZjM5NGE5ZmI4ZTJjYmM3ZDI3ZDhhM2YyIiwic2RfaGFzaCI6IkVNRkxWek0tX2tnZ2pxRF8tLVU5ODk5ZEc1YTV6dXdLLU5RT2IyVlVfQTAifQ.TW3sdg7Ktn1_E5QaVoJFDCIpmXrs9Dxahpysli8mhTGGaeaP8z9oETZn3fkWVEiFkAmAnKePYGHu-QiM14-Kpg%22%5D%7D&state=2638e05bc0cda0a626f2642626203fce

I tried to implement the SD-JWT with KB as per the example of @ubamrein but no changes in the output.

[muisit]

okay, must have been a configuration on my side. I rewrote the code a bit and now I get an audience mismatch error, which at least indicates the vp_token is received. Seems to have been my bad.

[muisit]

Credential Proof Not Accepted

DIIP test case 3, I send the following credential request:
{ proofs: { jwt: [ 'eyJhbGciOiJFUzI1NiIsInR5cCI6Im9wZW5pZDR2Y2ktcHJvb2Yrand0Iiwia2lkIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2lkWE5sSWpvaWMybG5JaXdpWVd4bklqb2lSVk15TlRZaUxDSjRJam9pVDNwU1ZpMVZlVUpsV1RCaWMySm5WRUl6TldOR1REQmZZM0JNUzBOWFlrcFNMVlZmWDBSZk0wSlVkeUlzSW5raU9pSlBWMWw0WWt4elN5MWZVMEZKTW1sUE4wdHlNWEJ6TW1kd09YaGtkSEZVVUdWV05FaExXRXhoTm5CbkluMCMwIn0.eyJhdWQiOiJodHRwczovL2l0Yi5pbGFicy5haS9yZmMtaXNzdWVyIiwiaWF0IjoxNzU4MDMxMDEzLCJleHAiOjE3NTgwMzE2NzMsIm5vbmNlIjoiNTIyNzhiNTk5OTEyNjU0OTA1N2I2ZDM1In0.j-I5X7Vr1-HC_GBXclVkSjOp-Ck1cL9-ScNeTcgMCIljxzPK9jHU5v-ud1Af-QqKs30uHTuftFVSbMXMd_etVA' ] }, credential_configuration_id: 'urn:eu.europa.ec.eudi:pid:1' }

I get the message {"error":"invalid_proof","error_description":"No usable JWT proof found in 'proofs'"}
This seems to follow the example in the ID-1 spec quite closely.

[endimion]

sorry for mising this. There was a bug on the server... deploying a fix and it should work now

[eklaver]

ITB Issuance Requests all fail

When I try to start a new issuance request, it immediately fails with the following error:

[2025-09-22 07:13:35] INFO - Starting session
[2025-09-22 07:13:35] INFO - Requesting issuance with session ID [b0f4f465-0e9a-4f14-aa31-edc5394507fb] from endpoint [https://itb.ilabs.ai/rfc-issuer/offer-tx-code].
[2025-09-22 07:13:35] ERROR - Unexpected error - step [Request credential issuance] - ID [1.2.1]
[SOAPFault]: No value present
[Soap]: No value present
[2025-09-22 07:13:36] INFO - Session finished with result [ERROR]

Could you please have a look at it? Thanks.

[endimion]

thanks for reporting :) Everything should be good now... cheers

[eklaver]

Great! Thanks, it works again!

[sanderPostma]

Hi @endimion

I am testing our browser based organizational wallet against the testbed, and I ran into two issues:
1.
Chrome is blocking requests to https://itb.ilabs.ai/rfc-issuer/credential-offer-no-code/...
This endpoint is missing CORS headers permitting access to it.
I could work around it for now by running my browser with the --disable-web-security flag, but no one should need to have something that risky enabled in the browser.

Our environment is rejecting your credentials because the status list it refers to has expired on September 18.

• (Any one who is still able to receive credentials is missing this validation)

[endimion]

hey @sanderPostma for 1 I will look into this and get back to you asap thanks!

for 2. can you please explain to me what you mean? you mean that the status list token you fetch is expired on the 18th? because it should be recreated each time you make I call to the endpoint I think... if this is what you mean I will need to look into this...

[sanderPostma]

The expired status list seems to be fixed now.
It was the exp value in https://itb.ilabs.ai/rfc-issuer/status-list/a9e1e0a5-abda-4b73-bc91-b4c8a008322c that pointed to September 18th.

But I also just got word from Niels that we should display a warning to the user when a statuslist or credential that is being offered has expired, but not refuse it outright.
Apparently there are some use cases for emitting expired credentials.

[endimion]

ok will check maybe I forgot some caching there :) cheers for reporting!

[goIDmobility]

Clarification on well-known url for credential issuer meta data

we’d like clarification on how .well-known URL resolution should work for the openid-credential-issuer discovery endpoint.
According to the [OpenID4VCI 1.0 specification], the resolution of the well-known URL should follow the approach of appending .well-known to the base issuer URL, followed by the path or subdomain. However, we noticed that your implementation of the discovery seems to differ from what is illustrated in the spec, while your OAuth Authorization Server discovery follows RFC 8414 correctly.

Here’s a comparison:

Spec Example (OID4VCI 1.0):

Issuer URL:
https://issuer.example.com/tenant

Credential Issuer Metadata:

https://issuer.example.com/.well-known/openid-credential-issuer/tenant

OAuth Authorization Server (RFC 8414):

https://issuer.example.com/.well-known/oauth-authorization-server/tenant

Your Implementation (FINDENET):

Issuer URL:
https://itb.ilabs.ai/rfc-issuer
Credential Issuer Metadata:
https://itb.ilabs.ai/rfc-issuer/.well-known/openid-credential-issuer
OAuth Authorization Server (RFC 8414):
https://itb.ilabs.ai/.well-known/oauth-authorization-server/rfc-issuer

Also referring this spec for wellknown configuration
https://www.rfc-editor.org/rfc/rfc8615.txt

This raises a few questions:

1. Did you intentionally choose to resolve openid-credential-issuer differently from the spec’s examples as per Draft 15?
2. Is this based on draft-15 behavior, since the draft did not provide a clear example when subdomains or paths are involved?

[nklomp]

No it is not. DIIPv4 is using Draft 15 not OIDVCI 1.0. It simply didn't have that concept explained yet.
Simply appending to the issuer value is the correct approach

[endimion]

in any case I have left support for both approaches... While I agree about not being part of d15 .. @nklomp why do you say that simply appending is the correct approach? The other way seems valid as well no? The correct thing to do would be in my opinion to do a small update on the DIIPv4 spec to clearly state this... ?

[nklomp]

Because in VCI draft 15 this was the text:

Credential Issuers publishing metadata MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-credential-issuer to the Credential Issuer Identifier. If the Credential Issuer value contains a path component, any terminating / MUST be removed before appending /.well-known/openid-credential-issuer.

So the logic changed after draft 15

[endimion]

ok I will revert the change... cheers

[nklomp]

And yes post draft 15 is the correct approach. .well-knowns also in sub paths would become a mess, because you use them for discovery purposes

[hacdias]

mDOC credential claimsdefinition in issuer metadata

Hi! We were running the testbed, and we might've found an issue with the issuer metadata available at https://itb.ilabs.ai/rfc-issuer/.well-known/openid-credential-issuer. The urn:eu.europa.ec.eudi:pid:1:mso_mdoc credential has a non-conforming claims description:

"urn:eu.europa.ec.eudi:pid:1:mso_mdoc": {
  (...)
  "claims": [
    {
      "path": [
        "urn:eu.europa.ec.eudi:pid:1"
      ],
      "claims": [
        {
          "path": [
            "given_name"
          ],
          "display": [
            {
              "name": "Given Name",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "family_name"
          ],
          "display": [
            {
              "name": "Surname",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "birth_date"
          ],
          "display": [
            {
              "name": "Birth Date",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "age_over_18"
          ],
          "display": [
            {
              "name": "Age Over 18",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "issuance_date"
          ],
          "display": [
            {
              "name": "Issuance Date",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "expiry_date"
          ],
          "display": [
            {
              "name": "Expiry Date",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "issuing_authority"
          ],
          "display": [
            {
              "name": "Issuing Authority",
              "locale": "en-GB"
            }
          ]
        },
        {
          "path": [
            "issuing_country"
          ],
          "display": [
            {
              "name": "Issuing Country",
              "locale": "en-GB"
            }
          ]
        }
      ]
    }
  ]
}

There are two issues as far as I can see:

• The claims objects should not be deeply nested: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-15.html#claims-description-issuer-metadata
• The path pointer for mDOCs must have two elements: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-15.html#appendix-C.2

[endimion]

should be deployed already :)

[hacdias]

Could it be that the value of https://itb.ilabs.ai/rfc-issuer/.well-known/openid-credential-issuer is getting cached somewhere? I'm still getting the old version.

[endimion]

you are right.. let me see what is going on.. ty!

[endimion]

should be ok now...

please have a look when able and again thanks for reporting

[hacdias]

Thank you!

[hacdias]

No code_challenge_methods_supported in the Authorization Server Metadata

The authorization server metadata, found at https://itb.ilabs.ai/.well-known/oauth-authorization-server/rfc-issuer, seems to lack the code_challenge_methods_supported field for PKCE. However, PKCE seems to be mandatory for the tests in the testbed. Our code only creates a challenge if that field is present.

See RFC 8414 (https://datatracker.ietf.org/doc/html/rfc8414):

code_challenge_methods_supported
OPTIONAL. JSON array containing a list of Proof Key for Code
Exchange (PKCE) [RFC7636] code challenge methods supported by this
authorization server. Code challenge method values are used in
the "code_challenge_method" parameter defined in Section 4.3 of
[RFC7636]. The valid code challenge method values are those
registered in the IANA "PKCE Code Challenge Methods" registry
[IANA.OAuth.Parameters]. If omitted, the authorization server
does not support PKCE.

[endimion]

thanks for reporting! should be ok now!

[hacdias]

credential_request_denied ?

When trying to make a credential request, I'm continuously getting the following error:

{
  "error": "credential_request_denied",
  "error_description": "'proof' and 'proofs' MUST NOT both be present"
}

This is the request:

{
  "proofs": {
    "jwt": [
      "eyJhbGciOiJFUzI1NiIsInR5cCI6Im9wZW5pZDR2Y2ktcHJvb2Yrand0Iiwia2lkIjoiZGlkOmp3azpleUpyZEhraU9pSkZReUlzSW1OeWRpSTZJbEF0TWpVMklpd2llQ0k2SWtSS2RXWnhOR2wxYld4V2VFZ3hjVGg2U1hkbVdURk1aVEphVW1kTGNXRTJSRXh5Um1STFFrUk9TbXNpTENKNUlqb2lPRGx3VTJVNVYwcE1NV2xPYVVVNE0xbE5WMk5xU2pWbE5sRkNiblk0UzNoNFJVTkhXa3BHUm1JMVl5SjkjMCJ9.eyJpc3MiOiJ3YWxsZXQiLCJhdWQiOiJodHRwczovL2l0Yi5pbGFicy5haS9yZmMtaXNzdWVyIiwiaWF0IjoxNzU5NDc4MDI0LCJub25jZSI6Ijk4NDdmMWMzNzE3OTA2MTNiOGFlMWI5NCJ9.WDQIdWUzU59y82pR4lJTTVv9qdyP8SNjKIU8Di3jsSyznVZSfZtorSVzs6iMn5ICgwpEQuIrOwd_BT3ENKYPlA"
    ]
  },
  "credential_configuration_id": "urn:eu.europa.ec.eudi:pid:1"
}

Clearly, there's only proofs there, so I'm not sure if I'm doing something wrong or if it's on the testbed side.

[TimoGlastra]

Hey @endimion, any thoughts on the above issue? Let us know if you need any additional info

[endimion]

hey guys sorry for taking so long to get to this.. I missed the notification... a fix has been deployed... should work fine now.. if possible please let me know cheers!

[hacdias]

@endimion I'm still getting the same error with the same payload and endpoint. Could you double check?

[endimion]

hey sorry forgot to deploy.. fix deployed with a new release...

[eklaver]

DID:Web in ITB Test issuer not according to specs

Hi, during testing different wallets with our Verifier, we noticed that the ITB is too lenient on the did:web resolution. The DID document of the RFC issuer is available on two different URLs:

• https://itb.ilabs.ai/rfc-issuer/did.json
• https://itb.ilabs.ai/rfc-issuer/.well-known/did.json

According to the did:web specification the second URL should not resolve to the DID document, since a path is specified (see step 4, the path is /rfc-issuer). The result is that some of the personal wallets use this method and think they are DIIP v4 compliant. When testing with other Verifiers, the wallet fails to retrieve the DID document.

To be complete, here is the part of the did:web specification:

2.5.2 Read (Resolve)
The following steps MUST be executed to resolve the DID document from a Web DID:

1. Replace ":" with "/" in the method specific identifier to obtain the fully qualified domain name and optional path.
2. If the domain contains a port percent decode the colon.
3. Generate an HTTPS URL to the expected location of the DID document by prepending https://.
4. If no path has been specified in the URL, append /.well-known.
5. Append /did.json to complete the URL.
6. Perform an HTTP GET request to the URL using an agent that can successfully negotiate a secure HTTPS connection, which enforces the security requirements as described in 2.6 Security and privacy considerations.
7. Verify that the ID of the resolved DID document matches the Web DID being resolved.
8. When performing the DNS resolution during the HTTP GET request, the client SHOULD utilize [RFC8484] in order to prevent tracking of the identity being resolved.

[endimion]

good point... removed the .well-known endpoint

[endimion]

hey sorry forgot to deploy.. fix deployed with a new release...

[eklaver]

Great, thanks!

[hacdias]

Hi, I'm getting this error from the Test Bed, meaning I can't even start the tests.

[endimion]

hey should be ok now... thanks for reporting!

[hacdias]

Linkability of Status List and Credential Signing Keys

At the moment, we only support using the same issuer key when verifying the signature of the credential and its status list. We have noticed that the status list and the credentials are not signed using the same keys. The credential uses a did:jwk and the status list uses a did:web (in this case did:web:itb.ilabs.ai:rfc-issuer).

The specifications are not very clear: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-12#section-11.3, but it seems clear that the keys should either be either the same, either owned by the same entity (e.g. same did:web), or somehow cryptographically linked (e.g. via X509 trust chain).

Are there any plans to change this (maybe DIIP v5)? Or is there any link that I'm missing when it comes to linking the keys?

[samuelmr]

I do support @muisit's comment 14708883 in this thread. I believe there can be use cases where the status list issuer is not the credential issuer.

In those use cases, there is also value in signing the status list. The trust between the verifier and the status list issuer can be established in many ways. OpenID Federation is one. Alternatively, the identifier of the status list issuer can be specified in an ecosystem rulebook.

[endimion]

@k00ij This was not a deliberate configuration per se... More a case of not really considering the consequences... as the exact requirements where not specified... (and in other projects it has not come up yet...). My understanding is that there is a consensus to use the same key since additional trust frameworks have not been established in DIIP? I am deploying a fix and if needed can revert... just let me know

[hacdias]

@endimion I was hoping to run the tests now that the status list is signed by the same key, but I keep getting expired credentials (e.g., exp: 1776669937).

[endimion]

haven't deployed the update yet.. give me a hour to finish a meeting :) will also double check why you are getting an expired list...

[endimion]

hey deployed a new version so feel free to test and let me know if I missed anything... (sorry for the delays.. had some issues with docker.. :/ )

[hacdias]

W3C VCDM 2.0 includes status claim?

I am wondering about the status claim in the W3C VCDM 2.0 provided in the tests. It is the same as the one in the SD-JWT VC. As per the specification, it can be applied to any JOSE/COSE-secured tokens.

At the moment, we don't verify it for W3C VCDM 2.0. The spec for W3C VCDM 2.0 already has its own credentialStatus claim as defined in here: https://www.w3.org/TR/vc-data-model-2.0/#status and the VCDM 2.0 JOSE spec only mentions that claim as part of the validation process: https://www.w3.org/TR/vc-jose-cose/#validation-algorithm

Are there any plans to change this, or clarify the reasoning behind it? I'd personally expect that the W3C VCDM 2.0 would only use the credentialStatus claim, no matter in which format it is transmitted (SD-JWT or not), while only SD-JWT VCs would use the status claim.

[TimoGlastra]

@samuelmr while extensions may be possible, all of these methods still use the credentialStatus property, not the status property a used by token status list.

I don't see why we would like to further deviate from the W3C way of doing things.

Either way it's not defined in DIIP V4 and thus doesn't feel right to make it part of the conformance test for now.

[k00ij]

290 / 5,000
I wonder if @endimion deliberately configured this test case this way. I don't recall us specifically discussing this. @endimion : was it a conscious configuration to sign the issuer and the status list with different keys (instead of both using the same DID:Web)?

[samuelmr]

I don't see why we would like to further deviate from the W3C way of doing things.

My understanding was that a W3C credential could use the credentialStatus property to refer to an IETF Token Status List.

It seems that doesn't work, since 6.2 requires the credential to have the status property. :(

Side note: I get the feeling that the OpenID/IETF camp deliberately wants to disallow combining W3C DM credentials with their specs. If that is the case, it is somewhat unfortunate from the DIIP perspective. Perhaps we should restructure the DIIP v5 to have clearly separated requirements for SD-JWT VC credentials and W3C DM credentials.

[nklomp]

To me what should happen is bring this to the editors of the ietf token statuslist. In essence this is only the naming of a reference to a statuslist. The VCDM one is slightly different. If token statuslist either makes a mention that name should be used but for VCDM credentials the VCDM names should be used then we should be good. Afaik nothing technically would be in the way of that approach.

[nklomp]

Also although the spec mentions how the reference should look like it clearly only has its supported credential formats in mind. Given the above and VCDM in the main data model spec already has defined how statuslist references should look like, the even better approach would be to have ietf token maken the location non normative in the statuslist spec and then incorporate normative text in the sd-jwt vc spec.

[eklaver]

[laugh] Eelco Klaver reacted to your message:

…

________________________________ From: Nikos Triantafyllou ***@***.***> Sent: Monday, October 20, 2025 7:31:05 AM To: FIDEScommunity/DIIP ***@***.***> Cc: Eelco Klaver ***@***.***>; Mention ***@***.***> Subject: Re: [FIDEScommunity/DIIP] DIIP V4 Test Bed (Discussion #59) haven't deployed the update yet.. give me a hour to finish a meeting :) will also double check why you are getting an expired list... — Reply to this email directly, view it on GitHub<#59 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAELVVTCNNW4M32RNITVZ233YSFTTAVCNFSM6AAAAAB7IEZWHCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINZSGY2DEOA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[hacdias]

Presentation verifier attestation should be an object

During the presentation test, I'm getting the following verifier_attestations:

 "verifier_attestations": [
    "eyJhbGciOiJFUzI1NiIsImtpZCI6ImRpZDp3ZWI6aXRiLmlsYWJzLmFpOnJmYy1pc3N1ZXIja2V5cy0xIiwidHlwIjoiand0In0.eyJpc3MiOiJkZWNlbnRyYWxpemVkX2lkZW50aWZpZXI6ZGlkOndlYjppdGIuaWxhYnMuYWk6cmZjLWlzc3VlciIsInN1YiI6ImRlY2VudHJhbGl6ZWRfaWRlbnRpZmllcjpkaWQ6d2ViOml0Yi5pbGFicy5haTpyZmMtaXNzdWVyIiwiaWF0IjoxNzYwOTQ1MzAxLCJleHAiOjE3NjA5NDg5MDEsImF0dGVzdGF0aW9uIjp7InBvbGljeV91cmkiOiJodHRwczovL2l0Yi5pbGFicy5haS9yZmMtaXNzdWVyL3BvbGljeS5odG1sIiwidG9zX3VyaSI6Imh0dHBzOi8vaXRiLmlsYWJzLmFpL3JmYy1pc3N1ZXIvdG9zLmh0bWwiLCJsb2dvX3VyaSI6Imh0dHBzOi8vaXRiLmlsYWJzLmFpL3JmYy1pc3N1ZXIvbG9nby5wbmcifX0.JT84279E4IQoe8-vhbBp3NtZuoklJlLq7t6YYV3VG7cKuA1wfY6CsmXTPe8nmgRFG296o9K8EaKJowcrdstrKA"
  ]

Which is failing our validation. I double checked the specification and it seems that the verifier attestations should be an array of objects, and not strings: https://openid.net/specs/openid-4-verifiable-presentations-1_0-28.html#section-5.1:~:text=type%20specific%20parameters%0A%7D-,verifier_attestations,-%3A and https://openid.net/specs/openid-4-verifiable-presentations-1_0-28.html#verifier-attestations.

[endimion]

good catch... will push an update on this as well

[TimoGlastra]

I'm curious why the verifier attestation is included, since DIIP does not specify anything about this. I think it's better to keep the conformance tests focused on what's specified in DIIP.

Do people use this for projects built on DIIP?

[endimion]

I cannot really answer on the project aspect. Of course the verifier attestation is optional so if DIIP scopes it out more than happy to remove... In other words will remove with the update and if there is need to re-added it will be added with the correct structure...

[nklomp]

I agree that it makes little sense to include more things than strictly necessary as it could result in implementors going in the wrong direction

[k00ij]

I agree. Let's remove for now and not include optional features in the DIIPv4 test cases.

[samuelmr]

Is the test bed down? We get this error message when trying to run tests:

Unexpected Error
An unexpected error occurred.

Error reference: QUWRMVZROV

[endimion]

everything should be working now again.. thanks for reporting.. . and let me know if something is still off :)