The guidance in Aries RFCs is that when base64url encoding is used, the = padding SHOULD be removed by the sender, and the recipient MUST handle receiving both padded and unpadded base64url encodings. The latter is a defensive approach in case the sender doesn’t follow the rules. The need to remove the padding is exacerbated in the OOB handling because the encoding string is used as a HTTP URL argument and the use of = as a padding character must also be percent-encoded as the character is special in URLs.
This was raised in an Aries RFCs Issue that was discussed at an Aries Working Group meeting and merged.
This issue is to update ACA-Py to strip the = padding from the OOB base64url encoded string. Ideally, this will be done in as general a way as possible in ACA-Py, so that the same behavior is applied across the project. If an “across the board” change is too difficult to achieve, we can leave that for later — addressing just the immediate issue in this PR.
The guidance in Aries RFCs is that when base64url encoding is used, the
=padding SHOULD be removed by the sender, and the recipient MUST handle receiving both padded and unpadded base64url encodings. The latter is a defensive approach in case the sender doesn’t follow the rules. The need to remove the padding is exacerbated in the OOB handling because the encoding string is used as a HTTP URL argument and the use of=as a padding character must also be percent-encoded as the character is special in URLs.This was raised in an Aries RFCs Issue that was discussed at an Aries Working Group meeting and merged.
This issue is to update ACA-Py to strip the
=padding from the OOB base64url encoded string. Ideally, this will be done in as general a way as possible in ACA-Py, so that the same behavior is applied across the project. If an “across the board” change is too difficult to achieve, we can leave that for later — addressing just the immediate issue in this PR.