I didn't understand this for a while but looking at the RFC PR, I think this is all that's needed.
Uses the common util in the wallet directory to remove the padding from the url via the bytes_to_b64 function. Then this same util module is used with b64_to_bytes which pads the invitation string when one is received. This was already in place, meaning that aca-py already handled unpadded invitation urls.
This util is used in several other places, mostly for attachment and jws signing. They all remove padding as well. The only place it looks to be used with padding is for bbs_bls_signature proof values. I'm not sure if this is required or not.
NOTE: I changed it for the old connection invitation endpoint as well even though is depreciated and didn't get update in the RFC.
I didn't understand this for a while but looking at the RFC PR, I think this is all that's needed.
Uses the common util in the wallet directory to remove the padding from the url via the
bytes_to_b64
function. Then this same util module is used withb64_to_bytes
which pads the invitation string when one is received. This was already in place, meaning that aca-py already handled unpadded invitation urls.This util is used in several other places, mostly for attachment and jws signing. They all remove padding as well. The only place it looks to be used with padding is for bbs_bls_signature proof values. I'm not sure if this is required or not.
NOTE: I changed it for the old connection invitation endpoint as well even though is depreciated and didn't get update in the RFC.