Use trinsic wallet to scan the QR Code, return error message "invalid QR Code"，what should I do

[yejiying]

Start the demo according to the steps, use the django demo, and use the trinsic wallet on the iPhone to scan the QR code displayed on the browser, and the error message will be displayed on the wallet, the message is " Error invalid QR Code". trinsic wallet app , use the latest version on the app store， demo code，clone the latest code from master

[esune]

Sometimes ngrok seems to time out due to a high volume of requests - which I have not yet been able to pinpoint.

Please check that your ngrok tunnel is still active, otherwise the mobile wallet (Trinsic, in this case) will not be able to address your vc-authn agent and will throw that error.

[ianco]

The "free" ngrok is rate-limited and also will timeout after some period of time

[esune]

The "free" ngrok is rate-limited and also will timeout after some period of time

It's the rate limit that while it isn't anything too demanding seems to be affecting the demo - something I'll investigate and tweak. Unless the QR code page is left sitting there for several minutes without responding to the request everything should work just fine.

[foxbike]

Same problem for me. Not working with Trinsic, Esatus but work with Lissi. Any solution?

[esune]

Same problem for me. Not working with Trinsic, Esatus but work with Lissi. Any solution?

I just tested with Trinsic and worked for me - v3.1.0 on Android

If you tested Lissi first, and then eSatus and Trinsic you likely incurred in the rate-limit issue described above and may need to restart the demo (including the ngrok tunnel).

[esune]

@yejiying @foxbike This setting can be used to increase the interval between poll requests, reducing the chances of rate-limiting issues with ngrok.

The reason it has not been changed from the default 2s interval is that it would make the demo much less responsive for users trying it - however if you plan on testing multiple wallets at the same time you can try and increase the interval.

[foxbike]

Thanks for answer. But our setup is on Openshift. No ngrok used. I see this pool url https://vc/connect/poll?pid=44622abb-8ec7-4f8e-8dfe-8a820b01e47e on QR code page. This url does not exist and fail. Maybe, it's the problem.

[esune]

Thanks for answer. But our setup is on Openshift. No ngrok used. I see this pool url https://vc/connect/poll?pid=44622abb-8ec7-4f8e-8dfe-8a820b01e47e on QR code page. This url does not exist and fail. Maybe, it's the problem.

That behaviour is correct: the url being polled will return 400 until the proof-request is submitted by the holder (mobile wallet) and verified by the vc-authn agent.

Which ledger are your agents connected to? Make sure your mobile wallet is on the same ledger as the vc-authn agent.

[yejiying]

The problem (invalid QR Code) still exists,

I set PollInterval=5000， and checked that ngrok tunnel was still active, and i modified these configurations before the commod "manage build"

The wallet network is sovrin staging network I use two wallets on Apple iOS： Trinsic and esatus

What‘s wrong?

[esune]

Another thing you can do is open the developer tools in the QR code page and inspect the DOM for a script tag that includes the proof-request for the JSON. Check the service endpoint section and make sure the URL that appears there is the ngrok one for the agent.

As I said before I was not able to reproduce the issue running it on my machine, without changing any settings, so I am a bit baffled at the error.

[foxbike]

If i decode the generated QR Code, i have this https:///url/d301d9b9-5ad0-49d1-8a34-872a24ca5037. This is an invalid qr code. What i'm missing. My installation is on Openshift.

[esune]

If i decode the generated QR Code, i have this https:///url/d301d9b9-5ad0-49d1-8a34-872a24ca5037. This is an invalid qr code. What i'm missing. My installation is on Openshift.

It looks like you have something configured wrong, he URL should be something like https://{controller-url}/url/{uuid}. The base url is set automatically here when in docker, the OpenShift template uses an environment variable.

Not having the endpoint resolve to a valid URL will cause the agent - any agent - to throw an error.

Perform a git reset to the latest head and try again, it appears that some settings have been modified and are not configured properly, and walk through the provided OpenShift templates again.

[esune]

My installation is on Openshift.

If your installation is on openshift I would recommend using the provided templates with the help of thesescripts that have been developed to support managing OpenShift projects: https://github.com/BCDevOps/openshift-developer-tools

[foxbike]

OK. But where i can set {controller-ngrok-url} with Openshift template for the controller?

[esune]

OK. But where i can set {controller-ngrok-url} with Openshift template for the controller?

If you look at the deployment configuration, you will find the APPLICATION_URL environment variable. Usually, this is a route that is generated by OCP for the service, unless you specify a different URL.

Using the openshift-developer-tools scripts is helpful when managing deployments, so I'd recommend again looking ito those as well.

[yejiying]

The deployment is still not successful, I don’t know what went wrong. Re-deploy the service on the ubuntu physical machine without changing any settings, access to scan the QR code or return an error message (invalid QR Code). The following is the script information of the QR code , ngrok information, and the decoding information of the base64 content in presReq

[esune]

The deployment is still not successful, I don’t know what went wrong.

Are you behind a firewall/proxy that may be interfering with the ngrok tunnel? Is your mobile wallet app using a VPN tunnel that may be interfering with the resolution of the ngrok address? Is your agent service up and running? Is the ngrok tunnel active (just try to hit it in a browser, or go to http://localhost:4040 to check the ngrok dashboard).

The invalid QR code message is usually displayed when the URL in the service decorator does not resolve to an Agent. As I mentioned, I was not able to reproduce the error locally (everything works as expected) so it must wither be something that is not configured 100% correct OR something that has to do with your Docker/network setup.

If you have an ngrok account you can try adding your auth token to the ngrok.yml configuration file (this would phase-out ngrok rate-limit issues).

[yejiying]

The two sets of services (change settings and without change any settings) previously deployed can scan QR code successfully on Android, but failed on IOS

[yejiying]

Android: Trinsic Wallet 3.1.0 IOS: Trinsic Wallet 3.1.3 esatus Wallet 1.10(build 11024)

[esune]

The two sets of services (change settings and without change any settings) previously deployed can scan QR code successfully on Android, but failed on IOS

If the ngrok tunnel has not been rate-limited or timed out and everything seems to work with one app/system and not the other you may have to contact the app maintainers then.

[yejiying]

ok，thanks

[milos-sol]

Hi @esune ,

I have the same issue. I started the demo according to the steps and tried with trinsic, esatus and lissi wallet on Android to scan the QR code displayed on the browser, but each time the error message was displayed in the wallet saying " Error invalid QR Code". Tried several times and each time first attempt was different wallet.

How I started the demo: first start von-network, then start ngrok on port 4040 (without that I get an error when I try to start demo) and finally start the demo. I also authenticated a New DID on a Ledger using DID and Verkey. Did I forget something? What else could I try to make it work?

I want to use this approach and implement it as another login option into my app.

Thanks a lot, really appreciate your help!

[esune]

@srbms23 make sure the agent container for vc-authn is running. The error you're having seems to indicate a malformed QR code, which is often caused by issues with the communication between vc-authn-controller and its agent (e.g.: the agent is not running at all).

[swcurran]

One debugging technique is to scan the QR code with your camera instead of a wallet app to see the encoded data and sharing that here. It might help with what is happening.

[esune]

One debugging technique is to scan the QR code with your camera instead of a wallet app to see the encoded data and sharing that here. It might help with what is happening.

That's a good suggestion. I was also going to add that if you use the browser's DOM explorer you will find a src tag at the bottom of the page with the JSON that is used as payload for the QR code. I would still check that the agent is actually running first, 90% of issues I've encountered are because of that (and you should also see the logs for vc-authn-controller indicate something went wrong there).

[milos-sol]

Hi @swcurran , @esune ,

I did everything as you said. These are the containers that are currently running so I think that should be ok.

The QR code is the problem while it doesn't contain any information. For example, encoded data from my QR code is: http://localhost:5000/url/b75c91e0-7cdf-4b55-a3e9-6d099be9ed9e

However, when I generate QR code out of didcomm as in picture below and scan it with lissi I get proof request in my wallet but when I type in my email, first name and last name, I cannot send it (Error: "Oops! Unable to process presentation request.").

Authorization was done with controller-api-key.

These are logs that I get from vc-authn-oidc_controller_1 in Docker LOGS:

[07:34:43 DBG] No matching request header found.
[07:34:43 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:43 DBG] Presentation request was not satisfied. AuthSession: [VCAuthn.Models.AuthSession]
[07:34:45 DBG] Processing authentication request for /vc/connect/poll.
[07:34:45 DBG] No matching request header found.
[07:34:45 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:45 DBG] Presentation request was not satisfied. AuthSession: [VCAuthn.Models.AuthSession]
[07:34:46 DBG] Processing authentication request for /vc/connect/authorize.
[07:34:46 DBG] No matching request header found.
[07:34:46 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:46 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:46 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:46 DBG] Request path /vc/connect/authorize matched to endpoint type VCAuthorize
[07:34:46 DBG] Endpoint enabled: VCAuthorize, successfully created handler: VCAuthn.IdentityServer.Endpoints.AuthorizeEndpoint
[07:34:46 INF] Invoking IdentityServer endpoint: VCAuthn.IdentityServer.Endpoints.AuthorizeEndpoint for /vc/connect/authorize
[07:34:46 DBG] Processing Authorize request
[07:34:46 DBG] Start client validation
[07:34:46 DBG] Start parsing Basic Authentication secret
[07:34:46 DBG] Start parsing for secret in post body
[07:34:46 DBG] Content type is not a form
[07:34:46 DBG] Start parsing for secret in query string
[07:34:46 DBG] client id without secret found
[07:34:46 DBG] Parser found secret: QueryStringSecretParser
[07:34:46 DBG] Secret id found: keycloak
[07:34:46 DBG] keycloak found in database: True
[07:34:46 DBG] client configuration validation for client keycloak succeeded.
[07:34:46 DBG] Public Client - skipping secret validation success
[07:34:46 DBG] Client validation success
[07:34:46 INF] {"ClientId": "keycloak", "AuthenticationMethod": "NoSecret", "Category": "Authentication", "Name": "Client Authentication Success", "EventType": "Success", "Id": 1010, "Message": null, "ActivityId": "0HMAHJ29KI7G0:000000DE", "TimeStamp": "2021-07-28T07:34:46.0000000Z", "ProcessId": 9, "LocalIpAddress": "::ffff:172.19.0.7:80", "RemoteIpAddress": "::ffff:172.19.0.1", "$type": "ClientAuthenticationSuccessEvent"}
[07:34:46 DBG] Status: [OK], Content: [{"result": {"did": "Th7MpTaRZVRYnPiabds81Y", "verkey": "FYmoFw55GeQH7SRFa37dkx1d2dZ3zUF8ckg7wmL7ofN4", "posture": "public"}}, Headers: [Date: Wed, 28 Jul 2021 07:34:46 GMT
Server: Python/3.6 aiohttp/3.6.3
]
[07:34:46 DBG] Status: [OK], Content: [{"initiator": "self", "role": "verifier", "auto_present": false, "thread_id": "1a981ce4-2a44-4e6e-a30a-5527230554a5", "created_at": "2021-07-28 07:34:46.829896Z", "trace": false, "updated_at": "2021-07-28 07:34:46.829896Z", "state": "request_sent", "presentation_request": {"name": "Basic Proof", "version": "1.0", "requested_attributes": {"3362ca2a-a03b-4176-bfbc-4f775dd77666": {"name": "email", "restrictions": []}, "d720875c-7aa8-4a02-a452-d2d8547b715c": {"name": "first_name", "restrictions": []}, "b88874bf-8c0b-4d5e-a20d-30c7aea94bb6": {"name": "last_name", "restrictions": []}}, "requested_predicates": {}, "nonce": "124958542531770715712046"}, "presentation_request_dict": {"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation", "@id": "1a981ce4-2a44-4e6e-a30a-5527230554a5", "request_presentations~attach": [{"@id": "libindy-request-presentation-0", "mime-type": "application/json", "data": {"base64": "eyJuYW1lIjogIkJhc2ljIFByb29mIiwgInZlcnNpb24iOiAiMS4wIiwgInJlcXVlc3RlZF9hdHRyaWJ1dGVzIjogeyIzMzYyY2EyYS1hMDNiLTQxNzYtYmZiYy00Zjc3NWRkNzc2NjYiOiB7Im5hbWUiOiAiZW1haWwiLCAicmVzdHJpY3Rpb25zIjogW119LCAiZDcyMDg3NWMtN2FhOC00YTAyLWE0NTItZDJkODU0N2I3MTVjIjogeyJuYW1lIjogImZpcnN0X25hbWUiLCAicmVzdHJpY3Rpb25zIjogW119LCAiYjg4ODc0YmYtOGMwYi00ZDVlLWEyMGQtMzBjN2FlYTk0YmI2IjogeyJuYW1lIjogImxhc3RfbmFtZSIsICJyZXN0cmljdGlvbnMiOiBbXX19LCAicmVxdWVzdGVkX3ByZWRpY2F0ZXMiOiB7fSwgIm5vbmNlIjogIjEyNDk1ODU0MjUzMTc3MDcxNTcxMjA0NiJ9"}}]}, "presentation_exchange_id": "faf8ca68-419d-46b2-b03b-4e2aeb5652db"}, Headers: [Date: Wed, 28 Jul 2021 07:34:46 GMT
Server: Python/3.6 aiohttp/3.6.3
]
[07:34:46 DBG] Processing authentication request for /controller-api-key/topic/present_proof/.
[07:34:46 DBG] No matching request header found.
[07:34:46 DBG] AuthenticationScheme: API Key was not authenticated.
[07:34:46 DBG] Received web hook update object : {"created_at":"2021-07-28T07:34:46.829896Z","initiator":"self","presentation_exchange_id":"faf8ca68-419d-46b2-b03b-4e2aeb5652db","updated_at":"2021-07-28T07:34:46.829896Z","connection_id":null,"state":"request_sent","thread_id":"1a981ce4-2a44-4e6e-a30a-5527230554a5","presentation_request":{"name":"Basic Proof","version":"1.0","requested_attributes":{"3362ca2a-a03b-4176-bfbc-4f775dd77666":{"name":"email","restrictions":[]},"d720875c-7aa8-4a02-a452-d2d8547b715c":{"name":"first_name","restrictions":[]},"b88874bf-8c0b-4d5e-a20d-30c7aea94bb6":{"name":"last_name","restrictions":[]}},"requested_predicates":{},"nonce":"124958542531770715712046"},"presentation":null,"verified":false}
[07:34:46 DBG] Presentation Request not yet received, state is [request_sent]
[07:34:47 DBG] Processing authentication request for /vc/connect/poll.
[07:34:47 DBG] No matching request header found.

Why is QR code not correctly generated, in what file should I take a look? Do you know what I should change to be able to send proof request from lissi?

Thanks for your help and time!

[esune]

Can you decode and post the base64 string you can see after didcomm://launch?d_m= please?

What do you mean by "type email, first and last"? It should be prompting you to pick a credential that you have in your wallet, not entering self-attested attributes - that is wrong as the proof-request has restrictions on schema you must use (see here). Do you have a credential from https://email-verification.vonx.io in your wallet? Have you posted the above configuration as described in the docs?

[milos-sol]

Base 64 Code: eyJAaWQiOiI5MGFhNWQwZC0wZjM1LTQ3YWUtODg2Ny1kNDUzZjk2MDY5ZDAiLCJAdHlwZSI6ImRpZDpzb3Y6QnpDYnNOWWhNcmpIaXFaRFRVQVNIZztzcGVjL3ByZXNlbnQtcHJvb2YvMS4wL3JlcXVlc3QtcHJlc2VudGF0aW9uIiwicmVxdWVzdF9wcmVzZW50YXRpb25zfmF0dGFjaCI6W3siQGlkIjoibGliaW5keS1yZXF1ZXN0LXByZXNlbnRhdGlvbi0wIiwibWltZS10eXBlIjoiYXBwbGljYXRpb24vanNvbiIsImRhdGEiOnsiYmFzZTY0IjoiZXlKdVlXMWxJam9pUW1GemFXTWdVSEp2YjJZaUxDSnVZVzFsY3lJNmJuVnNiQ3dpZG1WeWMybHZiaUk2SWpFdU1DSXNJbTV2Ym1ObElqb2lOamc1TURRNU1EVXpNalV6TXpnME5USXpNVGM1TmpraUxDSnlaWEYxWlhOMFpXUmZZWFIwY21saWRYUmxjeUk2ZXlJd01ETmpZV0ZoWXkweFpEYzNMVFJpTkRFdFlXTXhNaTB4WkRReVkyUXdObUppTW1NaU9uc2libUZ0WlNJNkltVnRZV2xzSWl3aWNtVnpkSEpwWTNScGIyNXpJanBiWFgwc0lqUmhaamRqWm1RekxUYzJZV1l0TkRSa05TMDVZamMxTFdRMU1tWTJOekl4TVdJMk5DSTZleUp1WVcxbElqb2labWx5YzNSZmJtRnRaU0lzSW5KbGMzUnlhV04wYVc5dWN5STZXMTE5TENKbFlqZGlPR05sWkMxbU0yUTJMVFJrTUdNdFlUUTNPUzB3WVRFd05qZGxaV1ptTVRFaU9uc2libUZ0WlNJNklteGhjM1JmYm1GdFpTSXNJbkpsYzNSeWFXTjBhVzl1Y3lJNlcxMTlmU3dpY21WeGRXVnpkR1ZrWDNCeVpXUnBZMkYwWlhNaU9udDlmUT09In19XSwiY29tbWVudCI6bnVsbCwifnNlcnZpY2UiOnsicmVjaXBpZW50S2V5cyI6WyJGWW1vRnc1NUdlUUg3U1JGYTM3ZGt4MWQyZFozelVGOGNrZzd3bUw3b2ZONCJdLCJyb3V0aW5nS2V5cyI6bnVsbCwic2VydmljZUVuZHBvaW50IjoiaHR0cDovLzE5Mi4xNjguNjUuMzo1Njc5In19

I didn't have credential in my wallet but even now when I have it after I scan this QR code: I get to type in my first name, last name and email. That's weird... Here is the screen shot of lissi wallet after I scan QR code:

My post request is just as in docu:

[swcurran]

With no restrictions on the Proof Request, the wallet (LISSI?) treats the attributes as self-attested and doesn't attempt to find a matching credential. If you can add a restriction to either a schema, schema creator DID, cred def creator DID or cred def, you would have it working, I think.

[esune]

I do not know why providing self-attested attributes is not working - this may be a question better suited for Lissi.

I would recommend getting a verified email credential from https://email-verification.vonx.io and using this proof configuration to test the functionality.

[swcurran]

Ah..sorry is that the issue? I'm pretty sure that LISSI does not support self-attested attributes. This has come up before with the LISSI wallet. I thought that is what LISSI was allowing you to do that -- which I found surprising.

[ntsbs]

It is not that Lissi does not support self-attested attributes, it is just that we seem to interpret them in another way.

{"name":"Basic Proof","names":null,"version":"1.0","nonce":"68904905325338452317969","requested_attributes":{"003caaac-1d77-4b41-ac12-1d42cd06bb2c":{"name":"email","restrictions":[]},"4af7cfd3-76af-44d5-9b75-d52f67211b64":{"name":"first_name","restrictions":[]},"eb7b8ced-f3d6-4d0c-a479-0a1067eeff11":{"name":"last_name","restrictions":[]}},"requested_predicates":{}}

The given proof request has no restrictions set, so we do not search for credentials with matching attributes, we let the user type (self-attested) whatever he wants, which allows him to answer the given proof request even if he has no credentials.

If you want the app to select an existing credential (attested by an issuer) in the user's wallet, the verifier has to define at least a schema in the restrictions array. In my opinion this is also more reliable than selecting all credentials which happen to have attributes named as requested by the proof request.

[swcurran]

Thanks for the explanation @ntsbs -- that makes sense. Two thoughts on this:

First, we should get agreement on this in the RFC 0441 Present Proof Best Practices. Anyone want to do a PR to that to propose a "best practice" handling so that implementations know what to do?

Second, my (not particularly strong) thoughts on this issue. Since the Indy AnonCreds implementation the idea of matching based credentials based on just the name of the field in a schema, my suggestion is that we go with the idea of just passing the presentation request to the search routine in the AnonCreds implementation. I think that is the expectation of the (few) people that have done this. If nothing is returned AND there are no restrictions, then the user should be given the option of self-asserting a value.