Obscure error messages in UI

[reinkrul]

First of all, I'm not an Android or mobile app developer so my issue might due to me having a very hard time debugging the application. So sorry in advance, if that's the case. In any case, thanks for providing an open source implementation of a OpenID4VC wallet.

At Nuts (https://github.com/nuts-foundation/) we're building a OpenID4VC and OpenID4VP-compatible wallet, issuer, and verifier. I'm trying to get our OpenID4VP implementation working with the Sphereon Wallet on Android, but came across some obscure error messages which I solved by digging into the app's code and SDK, but could use some more TLC. The errors below are shown as toasts when scanning a QR code:

Passing request as parameters instead of using request URI

undefined is not an object (evaluating 'r.qrData.uri.split('?request_uri=')[1].trim')

Due to: verifier sending the authz request as URL parameters, instead of referring to the request object by using the request_uri parameter. This also indicates the wallet does only support passing the request object through request_uri?

Using incorrect/unsupported app link URI scheme

Kan informatie niet ophalen. Fout: null is not an object (evaluating 'e.match(/^[a-zA-Z-_]+:\/\/)/g)[0]').

Due to: QR code app link was openid:?request_uri=(etc) instead of starting with openid://. Also, the latest OpenID4VP draft (v18) specifies openid4vp:// as example (but then later as openid4vp:), but this scheme does not seem to be normative? (see https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-10.1.2)

Not specifying constraints in presentation definition

Fout: Missing {{errorMessage}} value

Due to: not specifying any constraints in a JWT-VC-profile id_token authz request (property path in request: claims['vp_token']['presentation_definition']['constraints')).
Also: I couldn't determine whether this field is actually required.

[nklomp]

Hi @reinkrul Thanks for the feedback. Tthe whole qrCode reader needs to be refactored ASAP. We will be replacing that with xstate so we can decouple more things nicely.

Indeed the errors need to become human readable errors. The wallet currently still is very much in an alpha state.

The wallet indeed does seem to make an assumption that the request object comes from a URI which obviously isn't always the case. Our lower level libraries and SDK do not make that assumption. We expect to fix some of these issues as well as have some preliminary support for SIOPv2 V12 (now V11) and OID4VP V18 (now V11)

[reinkrul]

Thanks for the reply. Is it useful if I were to record all "obscure" (according to my opinion) error messages here, I come across?

[nklomp]

That for sure would be appreciated yes 👍