Closed loneil closed 3 months ago
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
Addingdid:key
to a prefix then rejects with[Error: No decoder found for multibase prefix '2']
So this needs to be a valid recipient key.