raw base64url consistency?

[Moopli]

ACA-Py seems to be permissive, in a certain sense, with the format that a base64 attachment payload can take: b64_payload = unpad(set_urlsafe_b64(self.base64, True)). However, this still enforces that the message sender must convert their base64 payload to rawURL format.

For interop, we'll need to decide how we standardize, and ensure it gets into AIP2.0. aries-rfcs/#561 (and also specifying whether to include/exclude padding), for total consistency? If that's not possible, do we push to standardize attachment signatures on the way you're converting a base64 payload to unpadded base64URL?

[swcurran]

In several of the RFCs there is a line like this -- "NOTE: In receiving the out-of-band message, the base64url decode implementation used MUST correctly decode padded and unpadded base64URL encoded data."

Is that what we are talking about? Deeper than that?

[Moopli]

@swcurran That part is good, however when attachments are signed, then either: A. The recipient converts the payload to unpadded base64URL when assembling the detached payload and protected header into the signed data to verify the signature, in which case the sender must also convert the payload to unpadded base64URL to construct the signature. or B. The recipient must accept the payload with or without padding, using it as-is when assembling the detached payload and protected header into the signed data for verification, in which case the sender is free to pad or not pad their attachment payload, and have less special handling to do when signing.

[andrewwhitehead]

Not sure if I'm missing something here, but signatures should be over the raw bytes of the payload, not the base64URL representation.

[Moopli]

That's a good point, the text conversion to raw base64URL, to satisfy the formatting requirement of JWS, is just a shortcut since the payload is already base64-encoded...

I suppose then, that the signature issue is not an issue at all - so unless we run into other issues where the base64 format is significant and unspecified, then I think all that's left here is to make sure that base64URL consistency gets into AIP2.0 (and preferably we'd pick either padded or unpadded across the board, rather than letting them freely mix, to minimize special handling).

[swcurran]

The decision made by the community is to send everything as base64url, but when decoding, accept either base64 or base64url, so if we are still receiving base64, everything still works. Note that we already (should be) decoding base64 with or without padding.

Here is a stackexchange on base64url decoding: https://unix.stackexchange.com/questions/628842/decode-encode-base64url-with-common-unix-tools

For ACA-Py, I think we need to do this:

• change decode to handle either as input. I think that means just assuming everything is a base64url, as if it is was encoded with base64, it will still work.
• if the "AIP 2.0" flag command line flag (we have that, don't we?) is set, send everything as base64url
• otherwise, leave what we are doing today (and a note on this issue what we do today).

Hope that makes sense. @shaangill025 -- could you please take this one?