fix(didcomm): tolerate base64url in signed attachment payloads

[genaris]

data.base64 in signed attachments is spec'd as standard base64, but peers routinely emit base64url (padded or not). Earlier Credo versions, AFJ 0.5.x, ACA-Py. Credo 0.7's TypedArrayEncoder.fromBase64 uses @scure/base which is strict, so DID Exchange responses (and any other signed-attachment flow) fail with:

Could not decode data from base64 string
  cause: padding: invalid, string should have whole number of bytes

So here we are creating some new helpers and updates in DidCommAttachment that do strict base64 first, fall back to base64url (stripping = to cover both padded and unpadded). DidExchangeProtocol makes use of this logic.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 94b8fb0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[berendsliedrecht]

Wait isn't it supposed to be base64url for data.base64 (i know confusing...)

• https://github.com/decentralized-identity/aries-rfcs/blob/main/concepts/0017-attachments/README.md#base64url
• https://identity.foundation/didcomm-messaging/spec/#attachments

I want to change it to base64url, but @TimoGlastra preferred not to, to keep better interoperability.

[genaris]

Wait isn't it supposed to be base64url for data.base64 (i know confusing...)

• https://github.com/decentralized-identity/aries-rfcs/blob/main/concepts/0017-attachments/README.md#base64url
• https://identity.foundation/didcomm-messaging/spec/#attachments

I want to change it to base64url, but @TimoGlastra preferred not to, to keep better interoperability.

The problem is that with the current code as it is right now on main, I have problems when trying to make it interact with a mediator using credo 0.5.17, so it already has an interop issue.

But you have a good point. Maybe we should first check for base64url and use base64 as a fallback? I'll explore this problem a bit more in detail to see what is actually going on here.

[genaris]

@berendsliedrecht initially I thought to take the same approach as we did in feat/didcomm-v2 branch, by modifying the TypedArrayEncoder to accept both, which seems to be actually the same behaviour as we had prior to upgrading to @scure/base (as Node's Buffer.from(x, 'base64') seems to accept both the standard and URL-safe alphabets, tolerating these missing padding/ignoring whitespaces/newlines.

So maybe it would be better to treat it as a regression of TypedArrayEncoder (and fix it to match the previous behaviour) rather than a specific case for DIDComm attachments. What do you think?

[berendsliedrecht]

I'd prefer to keep fromBase64 and fromBase64Url separate in the TypedArrayEncoder. I think its good to first try the spec-defined encoding and fallback if we know it deviates. I would rather be more explicit then having a function that does more.

[genaris]

I'd prefer to keep fromBase64 and fromBase64Url separate in the TypedArrayEncoder. I think its good to first try the spec-defined encoding and fallback if we know it deviates. I would rather be more explicit then having a function that does more.

Yeah, I agree. Better to keep it focused in DIDComm attachments and eventually remove the fallback once most agents are properly encoding them.