Mattr Labs v11 issuer throws 400 on credential request

[nklomp]

As brought up in #54 the new Mattrlabs V11 issuer doesn't seem to work with current VCI client.

The issue appears to be occuring in the Credential Endpoint

A new E2E test is created to track this issue.

It throws the following error with a HTTP 400:

{"code":"BadRequest","message":"Validation Error","details":[{"msg":"Invalid value","param":"type","location":"body"}]}

The error hints at the type param in the body. It could be that the issuer is still expecting a v8/v9 type in there. This has since moved to a types array.

I also noticed that the access token does not contain a c_nonce value, meaning we cannot set a nonce value in the JWT for the Credential Request. The spec does mention that this value is required in the request. Which then makes the remark about the c_nonce inconsistent, because the only way for a pre-auth flow to set the nonce is to actually get a c_nonce from the auth endpoint.

Additional payloads:

Note the c_nonce (and optional expiration of the nonce) missing Token response:

{
      "access_token": "SMyM_X7aZpIad5sCEgkAtT0xT3JPyNwzRt6Lf4rW9o5",
      "expires_in": 3600,
      "scope": "OpenBadgeCredential",
      "token_type": "Bearer"
}

Credential Request. Note it is using the types array from v11 instead of the previous type value from v8

{
  "types": [
    "OpenBadgeCredential"
  ],
  "format": "ldp_vc",
  "proof": {
    "proof_type": "jwt",
    "jwt": "eyJ0eXAiOiJvcGVuaWQ0dmNpLXByb29mK2p3dCIsImFsZyI6IkVkRFNBIiwia2lkIjoiZGlkOmtleTp6Nk1raTVad1pLTjFkQlFwcmZKVGlrVXZrRHhySGlqaWlRbmdrV3ZpTUY1Z3cySHYjejZNa2k1WndaS04xZEJRcHJmSlRpa1V2a0R4ckhpamlpUW5na1d2aU1GNWd3Mkh2In0.eyJhdWQiOiJodHRwczovL2xhdW5jaHBhZC52aWkuZWxlY3Ryb24ubWF0dHJsYWJzLmlvIiwiaWF0IjoxNjkxNzEzOTY2LCJleHAiOjE2OTE3MjExNjZ9.V09pI-L09VxoTpfEk8blmUDqojpqNkjdIcMSdwI8CBfjy-17rZsOLtKlq_SazOChoswK0CS1p_XYjb5lyT4JAg"
  }
}

The JWT header:

{
  "typ": "openid4vci-proof+jwt",
  "alg": "EdDSA",
  "kid": "did:key:z6Mki5ZwZKN1dBQprfJTikUvkDxrHijiiQngkWviMF5gw2Hv#z6Mki5ZwZKN1dBQprfJTikUvkDxrHijiiQngkWviMF5gw2Hv"
}

The JWT payload, which does not contain the required nonce value, because of no c_nonce provided in the token response

{
  "aud": "https://launchpad.vii.electron.mattrlabs.io",
  "iat": 1691713966,
  "exp": 1691721166
}

[nklomp]

In the JFF3 plugfest it has been confirmed by some successful issuance payloads that indeed the above type comes from a v8 concept, which has changed in v11. That means that the parties that were successful also allow v8 requests/responses with a v11 offer, which IMO should never be allowed.

The issuer metadata also seems to be v8, which in itself we support. We need to check whether our high-level client allows for an offer to be in v11 and then the metadata to be v8 however. Same applies; we should not allow for it, but we might be able to work around it, as we translate v8 into v11 if I am not mistaken

[nklomp]

This has been fixed for some time now