-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OOB format problem #545
Comments
Some relevant discussion on Credo Discord: https://discord.com/channels/1022962884864643214/1249796862379294820 |
I think what we should be doing here is actually calling ACA-Py to get an Out Of Band message. This would include the recipient key and proper service object naming. This would also future-proof things better as an ACA-Py OOB should be interoperable with Credo more than creating it manually in VCAuth would be. The current VCAuthN controller pattern instead:
I tried getting a OOB message from ACA-Py and hardcoding things (recipient key) into VCAuthN instead and this worked end-to-end with the BC Wallet. |
Agreed on using the ACA-Py generated message. The controller processing is likely a leftover from conenction-less handling, since there is no endpoint in ACA-Py to generate a conenction-less proof-request with the service endpoint as far as I know. We can implement the change and plan to phase-out connection-less in favour of always using OOB/did-exchange. |
When using VCAuth-N in OOB mode it fails to scan in BC Wallet. After some debugging in Credo with Bryce we've determined there are a few validation errors in the payload that comes back from the QR Code scan redirect
A sample OOB message (what the wallet gets from the QR code scan redirect response) body is something like this:
There are a couple different issues in the service object
The keys should be in camelCase (this is an easy alias fix in VCAuth-N model)
The recipient key is not right. It's just putting the wallet verkey in there. I don't know if this is valid in some cases, or an error in the vcauthn code(?) but Credo rejects it with
each value in recipientKeys must be a did:key string
Adding
did:key
to a prefix then rejects with[Error: No decoder found for multibase prefix '2']
So this needs to be a valid recipient key.
The text was updated successfully, but these errors were encountered: