Currently in the specs, the out-of-band messages are defined as a URI query parameter:
The _oob query parameter is required and is reserved to contain the DIDComm message string.
https://<domain>/<path>?_oob=<encodedplaintextjwm>
But would be great if we could define out-of-band messages using URI fragments.
Minor change in the way that we specify that _oob. We are talking about HTTP links.
https://<domain>/<path>#_oob=<encodedplaintextjwm>
Would be awesome if everyone support that both ways. If an application (DID Comm capable) is scanning a QRcode that is an out-of-band message they should look in the URL query parameter and then look in the URI fragments.
I think would be a great improvement for web apps and single-page applications.
Currently in the specs, the out-of-band messages are defined as a URI query parameter:
The _oob query parameter is required and is reserved to contain the DIDComm message string.But would be great if we could define out-of-band messages using URI fragments.
Minor change in the way that we specify that
_oob. We are talking about HTTP links.Would be awesome if everyone support that both ways. If an application (DID Comm capable) is scanning a QRcode that is an out-of-band message they should look in the URL query parameter and then look in the URI fragments.
I think would be a great improvement for web apps and single-page applications.