Removing Whitespaces before base64Url encoding

[arnoweiss]

What happens?

Base64url encoding is sensitive to whitespaces (like new lines). The spec makes no statements where Whitespaces in Base64Url-encoded json-payloads should be removed - serverside or clientside.

Why is this wrong?

If the servers assume that clients remove whitespaces, they will not match json-structures that are in fact equivalent.

How should it be fixed?

Make statement if server or client should remove whitespaces.

• I have signed the required Developer Certificate of Origin (DCO) already.

[sebbader-sap]

As we did not write anything demanding the removal of whitespaces, or line breaks etc., therefore I'd say adding a note like this should solve it:

Note 1: Clients may clean the serialised content by removing white spaces before applying the base64url encoding. However, servers must not expect it, therefore, must not expect that different encoded parameters map to different (unencoded) data objects. In fact, the same AAS data object could be encoded through different encoded values.

or similar...

[arnoweiss]

Yea, I like the approach. It should basically convey "Do the matching on the level of AAS-objects - not on encoded strings or unencoded json."

Adjacent topics:

• Given order of unordered elements (like in assetIds) is something else that must be ignored. When matching on the json-level, order would be considered as json assumes it in every list.
• Matching only a subset of the assetIds.
  • What happens when server holds object with specificAssetIds a, b, c and Client makes request for specificAssetIds a, b?
• Is the existence of optional fields (like specificAssetId/semanticId) relevant for matching?
  • Server holds semanticId for specificAssetId a, Client makes request without semanticId
  • Server holds no semanticId for specificAssetId a. Client makes request with semanticId.

[sebbader-sap]

PR has been merged.