[urn] Re: URN Namespace Registration for SAID (Self-Addres sing Identifiers)

Thank you, Lars! I’ve provided below some direct response to your question and what I think may address your question and comment in the registration text.

Best regards,
Wenjing


From: Lars G. Svensson <[email protected]>
Date: Monday, February 2, 2026 at 6:11 AM
To: Wenjing Chu <[email protected]>
Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: AW: [urn] Re: URN Namespace Registration for SAID (Self-Addressing Identifiers)

Hi Wenjing,

On Samstag, 31. Januar 2026 00:25, Wenjing Chu wrote:

Like Dale, I don't see anything that makes me opposing the registration of this namespace. However, I have one question and one comment.

Question:

> The hash/digest algorithm is encoded in the SAID, at least partially, for cryptographic agility. Applications may use different
> digest functions over a long period of time. Data with different digests may also merge. Self-encoding allows the overall
> system to evolve gracefully. Another example is PQC.

I just want to understand how the hash/digest algorithm is encoded. It doesn't seem to be descrbed explicitely in the registration, and I looked at the CESR documentation but couldn't find it there, either. Can you expand a bit on how this encoding is done and how verification algorithms can find that informtion?

>>>>>>>>>>>>>>>
The CESR specification has been officially approved recently by the Trust over IP community. I will cite the document in that way and replace the GitHub link. Let me check with them for an official citation method.

One of the basic ideas of CESR is to provide a two-way 1-to-1 mapping between raw bytes and Base64. Since a raw byte contains 8 bits and Base64 contains 6 bits of information, if we align data with 24 bits boundary (through padding) all the time, then we can have consistent 3 bytes <-> 4 Base64 mapping. From this basic structure, CESR encoding is defined over Text and Binary domains that maintain the property of composability : i.e. the transformation from one domain to another can be done over the concatenated data stream, equivalent to if each member is transformed then concatenated.

To differentiate, raw binary byte streams in a local machine is called Raw format. It can be converted to CESR Binary (and therefore Text) as described in Section 8.3.<https://trustoverip.github.io/kswg-cesr-specification/#concrete-domain-representations> (specifically 8.3.1)

The SAID string has two parts: the digest algorithm type code, and the encoded digest itself. The type code is defined in the CESR’s default code table (used by KERI/ACDC/TSP) - see Section 11.4<https://trustoverip.github.io/kswg-cesr-specification/#keriacdc-protocol-stack-tables>. The digest itself is converted from Raw to CESR Binary encoding, or Text to be used in urn:said or in text based data formats.

A verifier therefore must, at minimum, be able to recognize the digest algorithm type code and recognize or convert the CESR encoded SAID to Raw binary data.

>>>>>>>>>>>>>>

Comment:

You point to documentation that is on GitHub. My concern is about the long-term accessibility to that documentation (e. g. If GitHub goes out of business...). You might want to consider to use an address that you control (e. g. under the domain trustoverip.org) and then redirect that to GitHub (or wherever the documentation might be in future). That way you need not update the registration just because a third party platform goes out of business.

>>>>>>>>>>>>>>>>>>>>>>>
Yes - absolutely. As pointed out above, I think I will use an official citation and a link to the domain controlled by  the Trust over IP community.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Best,

Lars

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]