Error 500 upon sharing Presentation request on wallet.walt-test.cloud

[sebpalluel]

I get an error 500 when trying to authentify through the IDPKit when sharing a Presentation request.

Here is the request:

curl 'https://wallet.walt-test.cloud/api/wallet/siopv2/fulfillPresentation?sessionId=54cd9fe2-25a1-4cce-ba1c-86376e449f02' \
  -H 'authority: wallet.walt-test.cloud' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9,fr-FR;q=0.8,fr;q=0.7' \
  -H 'authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJzZWJwYWxsdWVsQGdtYWlsLmNvbSJ9.01X_LbGmxz2_OxSoO-y_rP3vNjJYg3TIsNVIELNnusQ' \
  -H 'content-type: application/json' \
  -H 'cookie: i18n_redirected=fr' \
  -H 'origin: https://wallet.walt-test.cloud' \
  -H 'referer: https://wallet.walt-test.cloud/CredentialRequest/?sessionId=54cd9fe2-25a1-4cce-ba1c-86376e449f02' \
  -H 'sec-ch-ua: "Chromium";v="106", "Google Chrome";v="106", "Not;A=Brand";v="99"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36' \
  --data-raw '[{"claimId":"0","credentialId":"urn:uuid:16985a4e-5f2f-44c3-8867-c4531e7d1f08"}]' \
  --compressed

And the request payload:

[{claimId: "0", credentialId: "urn:uuid:16985a4e-5f2f-44c3-8867-c4531e7d1f08"}]

To reproduce the issue, you can access my current test project on this branch, then launch all the services with pnpm start, access this page and either click on Walt.id IDPKit or on Keycloak

I'm using this account I have just registered and provided with a VC of type VerifiableID: sebpalluel@gmail.com / eyk7BCP@cvg@wka5gft

The same issue also happen when I'm connecting my Metamask wallet and sending an empty Presentation request.

[sebpalluel]

I managed to make it work with the IDPKit directly used as a provider in my Next App.
I've found the solution on your video

TLDR: I needed to generate a DID first with the 'DNS' ecosystem before requesting a VerifiableID.

I had to do the following:

1. Create a new account on the wallet
2. Go to the option
3. Select the DNS ecosystem
   
4. On the 'Step 2' write a random domain like 'test.com' and click on 'Generate DID'
   
5. Click on the 'Done' Button
   
6. Click on 'Request Credential'
7. Choose 'walt.id Issuer Portal' and 'VerifiableID', click on 'Fetch Credentials'
   
8. Put any credentials to go through the fake login page of the 'Demo Issuer Portal'
   
9. Select the 'Verifiable ID document' option and Confirm.

10 Accept the received credentials

10. After that I had to come back manually to my login page on http://localhost:3000/auth/signin to click on the 'Walt.id IDPKit' button
    
11. Accept the 'Presentation request' of 'Verifiable ID document' by clicking on 'Share'

The user is logged in effectively and created on the DB through Hasura (Next Auth do it automatically for a new account)

Here is the output of Next Auth:

[next-auth][debug][OAUTH_CALLBACK_RESPONSE] {
  profile: {
    id: 'did:key:z6MkedCY7K1z1jkRdZCh3t2LvHxqrNoVhAR6KZPZqGgCFsGB',
    email: undefined
  },
  account: {
    provider: 'identity-provider',
    type: 'oauth',
    providerAccountId: 'did:key:z6MkedCY7K1z1jkRdZCh3t2LvHxqrNoVhAR6KZPZqGgCFsGB',
    access_token: 'eyJraWQiOiJjMDQ3ZjRlNDJjZjU0YjY2YWQxNTRkOGNlNTFlMDNlZiIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiI4NmUyNWM2Ny1iYjU1LTQyYWYtOGJmNC1mNjljODVmNTAyMjMiLCJhdWQiOiJYaHJ2ZmVnS1RTaHFlYkxBTEVTTDVoaERqWTljMDRfVjVmbG5JQkRBYTFZIn0.cHjA7hEuaxEfTjA4SyKOvn7a0SHHMCVBoBaHhEktm88_UXcFTO4GoUIhSAB9JXm1CytG52jIzwhzms8dHVaavGKW4NACLxh1Gqm5EL5nGUJQu2MG5COjMpKG5x4srt3EPchcoa3f1Voq83_z6869WYDjbV5EPl6KRfKRLkA8sUn_gLrHKwCr98fU8wCXdfx7Ad6-D-TtcV_Sx35QRFYCB0iDzbCBeIflHEO4btg6LJ1am5j6mAtSH2aYeu7idY2ZB3iAgrGWJ4sRRgJ4ittazsUc1ZPNIANGfXCFtriEPVzwB7CQzJYF6LOObce4VXSFa7mpGTxDibwVDI7NSx3SUg',
    refresh_token: 'KzXwrDgCOWix1Mf00wDXge0MSKQFDefAyHytPTFtNek',
    scope: 'openid',
    id_token: 'eyJraWQiOiJjMDQ3ZjRlNDJjZjU0YjY2YWQxNTRkOGNlNTFlMDNlZiIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJkaWQ6a2V5Ono2TWtlZENZN0sxejFqa1JkWkNoM3QyTHZIeHFyTm9WaEFSNktaUFpxR2dDRnNHQiIsImF1ZCI6IlhocnZmZWdLVFNocWViTEFMRVNMNWhoRGpZOWMwNF9WNWZsbklCREFhMVkiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjkwODAvYXBpL29pZGMiLCJpYXQiOjE2NjQ5MDMyODl9.fsmo4DyVo29AxnoJGJwdF_tyN201gXIXqc6tKx26pBwJ2JS36m9EyMJruUyvx6432dPfc0B4f-ARGP-DHwg3kGblRtTwYqn-H17auGM70rYJkwK-R34l7OPt1KNLK9rKnjf_sXMbRCBMrhKwOp80d4pB4aJf6LBXNY6emi4v0APstb7um_esu8ODZG41Hq1d_g8SNzz3u_woOcH3OM-FOJZc_LsCNtxBfbIVLAFToIecSt0Irz8lhdAh4RR1qZb3LvsK_9VBA7tSLUn1SLUhOJM2Lfx8TrSzqa2oPi3CNbV2UAnrYNh0uNURVPHFR8eYy5Kdm0s_2XJXAvczsYFjcg',
    token_type: 'Bearer',
    expires_at: 1664903589
  },
  OAuthProfile: { sub: 'did:key:z6MkedCY7K1z1jkRdZCh3t2LvHxqrNoVhAR6KZPZqGgCFsGB' }
}

The working account credentials are test@test.com / test

I've tested with the Key ecosystem without success. The DID seem to be created but there is an error.

Also with the same account, after sharing the VerifiableID, I get this page with Keycloak:

[severinstampler]

Hi @sebpalluel
I figured out what your problem most likely is.
We have recently deployed an updated version of the walletkit to the walt-test.cloud deployment.
If you had a did:key in your wallet before this deployment, you will run into these kinds of issues with the presentation requests.
The solution is, to create a new did:key and select it as default did. Then it should also work with the did:key ecosytem.
Please let me know if it works for you.
br
Severin

[severinstampler]

Which problem are you referring to? The wallet backend sets the presentableCredentials property in this response, to let the UI know which credentials are available, that match the presentation definition. The matching is a bit more complicated, as the filter in the presentation definition object can be anything. The simple type filter here is just one example.
So the backend filters the credentials by DID and tries to match them to the filter in the presentation definition. Then it sets the presentableCredentials array. If no matching credentials are available the array is empty. The backend then tries to find issuers, that can issue the missing credentials and sets them in the availableIssuers property.
Now in this case the wallet will let the user select an issuer to trigger the issuance flow. When the issuance flow returns, it will continue with the presentation flow.

[sebpalluel]

Ok I understand what you mean.

So in case the user already have a presentableCredentials that match his DID and the presentationDefinition, I can confirm that the user flow works properly.

Otherwise I get this view:

The message Empty presentation requested, confirm to continue is appearing because this computed value requiredSchemaIds filter on the schema field of input_descriptors which is empty on the referenced config of the IDPKit. The issue is mentioned on the TODO:

requiredSchemaIds() {
      // TODO: adapt for Presentation exchange (2.0), where no schema uri is necessarily available
      return this.presentationSessionInfo.presentationDefinition.input_descriptors
      .filter(idesc => idesc.schema != null)
      .map(idesc => idesc.schema.uri)
    }

Moreover there is errors on the view where the functions are directly called, the @click event in vue is referencing to a callback. So it should take the reference of the function or an anonymous function, here the functions are directly called when the component is mounted.

diff --git a/pages/CredentialRequest.vue b/pages/CredentialRequest.vue
index 6dfe60d..d33ef6c 100644
--- a/pages/CredentialRequest.vue
+++ b/pages/CredentialRequest.vue
@@ -10,7 +10,7 @@
                     <input class="form-check-input me-4" type="checkbox" :id="'credential-' + credential.id" :name="'credential-' + credential.id" :value="credential.id" v-model="checkedCredentialIds">
                     </div>
                     <div class="col-10">
-                    <a @click="selectedCredential = credential">{{credential.title ? credential.title : $t('CREDENTIAL.TYPE.' + credential.type[credential.type.length-1]) }}</a>
+                    <a @click="() => selectedCredential = credential">{{credential.title ? credential.title : $t('CREDENTIAL.TYPE.' + credential.type[credential.type.length-1]) }}</a>
                     </div>
                   </div>
                 </div>
@@ -22,7 +22,7 @@
                   <em>No matching credentials found for the current DID</em>
               </div>
               <div class="_button mt-4" v-if="presentableCredentials.length > 0 || requiredSchemaIds.length == 0">
-                  <button href="#share" class="_share col-12 mb-2" @click="peSubmit()">Share</button>
+                  <button href="#share" class="_share col-12 mb-2" @click="peSubmit">Share</button>
                   <a href="#reject" class="_reject col-12">Reject</a>
               </div>
               <div class="mt-4" v-if="presentationSessionInfo.availableIssuers != null && presentationSessionInfo.availableIssuers.length > 0">
@@ -33,7 +33,7 @@
                   </option>
                 </select>
                 <div class="_button">
-                <button href="#fetch" class="_share col-12 mb-2" @click="fetchFromIssuer()" :disabled="selectedIssuer == null">Fetch credential from issuer</button>
+                <button href="#fetch" class="_share col-12 mb-2" @click="fetchFromIssuer" :disabled="selectedIssuer == null">Fetch credential from issuer</button>
                 </div>
               </div>
           </div>

[severinstampler]

Hi
I have recently changed the code regarding requiredSchemaIds. The web wallet doesn't have to interpret the presentation definition anymore, instead, the issuance request for the pending presentation will be assembled by the walletkit backend.
I suggest to try it again, once those updates are merged into the main branch.

[severinstampler]

Hi @sebpalluel
I think I just really understood why that problem occurs.
I suppose you don't send the profile scope with your authorization request, which is why the idpkit sends an empty presentation request.
Try to add the profile scope, so that it requests the VerifiableId credential (as configured by default).

Also, note I updated our deployments on walt-test.cloud today.
br

[sebpalluel]

Hi !
Thanks for the update. I can confirm that after the commit to add profile to the scope + an update of the verifier-config.json to have the new API URL for the siop request this is working smoothly for both an existing account and a new one.
You might want to update the idpkit doc with the new API URL: https://docs.walt.id/v/idpkit/configuration-and-setup/siop-manager-configuration#configuration-example

[severinstampler]

Hi @sebpalluel
I investigated your setup and found what the problem is:

1. Please make sure to pull the latest idpkit docker image, as there were recent changes in the OIDC protocol and the walt-test.cloud wallet follows the new implementation of the protocol.

2. To get the keycload integration working in your setup:
   You have configured KeyCloak to use our deployed instance on idp.walt-test.cloud, however, the client_id and client_secret are configured on your instance of idpkit inside the docker-compose setup.
   Therefore the client authentication won't work, as the idpkit on idp.walt-test.cloud doesn't accept your client_id and secret.
   Furthermore, the KeyCloak bug regarding the clientAuthMethod setting in the realm configuration (mentioned above) was not applied in your docker-compose setup.

I got the keycloak login working using the following configuration:

"identityProviders": [
    {
      "alias": "waltid-idpkit-test-cloud",
      "displayName": "Walt id test cloud",
      "internalId": "f0ae0286-6575-4972-a0b2-11efb85e4a51",
      "providerId": "oidc",
      "enabled": true,
      "updateProfileFirstLoginMode": "on",
      "trustEmail": false,
      "storeToken": false,
      "addReadTokenRoleOnCreate": false,
      "authenticateByDefault": false,
      "linkOnly": false,
      "firstBrokerLoginFlowAlias": "first broker login",
      "config": {
        "userInfoUrl": "http://idpkit:9080/api/oidc/userInfo",
        "validateSignature": "true",
        "hideOnLoginPage": "false",
        "tokenUrl": "http://idpkit:9080/api/oidc/token",
        "acceptsPromptNoneForwardFromClient": "false",
        "clientId": "0CYUXjimoqywONiXgaF6KAtsQw5kE7XhJ1qghdVdgq4",
        "uiLocales": "false",
        "jwksUrl": "http://idpkit:9080/api/oidc/jwkSet",
        "clientAuthMethod": "client_secret_basic",
        "backchannelSupported": "false",
        "issuer": "http://localhost:9080/api/oidc",
        "useJwksUrl": "true",
        "loginHint": "false",
        "pkceEnabled": "false",
        "authorizationUrl": "http://localhost:9080/api/oidc/authorize",
        "disableUserInfo": "false",
        "syncMode": "IMPORT",
        "clientSecret": "K92SRgYOk0k84Mu1gEHtfdK0x8otrYwLXTLCKkb8JZI",
        "allowedClockSkew": "0",
        "prompt": "none",
        "defaultScope": "openid profile"
      }
    }
  ],

Note: that some endpoints on the idpkit are accessed from within the docker-compose environment, which is why it needs to be accessed via the internal hostname http://idpkit. Whereas other endoints are called via the browser from outside docker-compose. Those need to be set to localhost.
Ideally one would set up the network in a way, that the idpkit instance is reachable from inside and outside via the same DNS name. That would be a bit of trial and error to figure out how to do it properly.

[severinstampler]

If you want to use the IDPKit on walt-test.cloud, we can provide client_id and client_secret for you. In that case, of course, you wouldn't need to run the idpkit in your docker-compose application at all.

[sebpalluel]

Thanks you very much for your answer and your solution, it works ! (Still have to resolve an issue on my end with the GraphQL server).

I see the issue with the resolving of the DNS from inside docker that is different from the host machine. I've came across this many time. I've found a solution that should work for Linux and Windows but sadly it doesn't do the trick for Mac: http://mageddo.github.io/dns-proxy-server/latest/en/1-getting-started/requirements/
I will try to find a script that work for each platform but otherwise, as long as it work, it's fine.

Thank you for the proposition to share the secret for your hosted IDPKit but I want to be able to keep control over the IDPKit config, also I don't want to leak your secret...