Bug Report
Describe the Bug
all participant IDs in the ISsuerService's Admin API are currently used in clear text. We should base64-encode them
Expected Behavior
app participant IDs are base64 url-encoded
Detailed Description
in many cases, the participant ID will be a DID, which contains colon characters (":"). In addition, Web DID's may contain ports which - according to the DID web spec must be url-encoded ("%3A").
For example, a DID like did:web:localhost%3A3006 would resolve to http(s)://localhost:3006. If we url-encoded such a DID, thus resulting in did%3Aweb%3Alocalhost%3A, it would become virtually impossible to distinguish segment separators (":") from port separators (":").
Base64-encoding the participant ID will solve that.
Possible Implementation
You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.
Bug Report
Describe the Bug
all participant IDs in the ISsuerService's Admin API are currently used in clear text. We should base64-encode them
Expected Behavior
app participant IDs are base64 url-encoded
Detailed Description
in many cases, the participant ID will be a DID, which contains colon characters (":"). In addition, Web DID's may contain ports which - according to the DID web spec must be url-encoded ("%3A").
For example, a DID like
did:web:localhost%3A3006would resolve tohttp(s)://localhost:3006. If we url-encoded such a DID, thus resulting indid%3Aweb%3Alocalhost%3A, it would become virtually impossible to distinguish segment separators (":") from port separators (":").Base64-encoding the participant ID will solve that.
Possible Implementation
You already know the root cause of the erroneous state and how to fix it? Feel free to share your thoughts.