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

Hi Wenjing,

Thanks to you and the team for these improvements to the registration 
request.

With regard to next steps in the process, let's hear from Dale and Lars 
as to whether the latest changes address their feedback.

With regard to the registration request, I have two small suggestions:

1. The Assignment section states "SAID strings conforming to this scheme 
are self-assigned". However, I feel it would be better to say something 
like this: "SAID URNs are algorithmically generated". Doing so makes it 
clear that assignment of SAID URNs is a managed process (the importance 
of which is emphasized in RFC 8141), where the management method is an 
algorithm (for which we have the precedent of UUID URNs as specified in 
RFC 4122).

2. The Resolution section states "we may extend this scheme with 
optional information for easier resolution". However, I feel it would be 
better to say something like this: "a future version of this 
registration may define optional information making it easier to resolve 
SAID URNs". Doing so effectively promises that the extensions will be 
documented and that the registration will be updated to reflect the 
newly defined extensions.

Peter
(expert review team lead)

On 3/12/26 1:36 PM, Wenjing Chu wrote:
> Thank you all for your comments and suggestions over this application! 
> Very much appreciated.
> 
> It took us a while to formally have a DOI for referencing the CESR 
> specification, but that finally came in.
> 
> So, the latest version now has:
> 
>   *
>     Citation with DOI, I kept the github link as well as a FYI
>   *
>     Clarifying explanation as suggested by Lars
>   *
>     The great SAID locator/format suggestion from Dale is noted as a
>     potential future improvement
> 
> 
> The latest application is attached and can also be accessed here: 
> https://github.com/trustoverip/kswg-said-urn-charter/blob/main/ 
> urn_application.txt <https://github.com/trustoverip/kswg-said-urn- 
> charter/blob/main/urn_application.txt>
> 
> I sensed that we may finally be close to completing this application. 
> What would be the next steps, process-wise?
> 
> Best,
> Wenjing
> 
> 
> *From: *Lars G. Svensson <[email protected]>
> *Date: *Thursday, February 5, 2026 at 1:34 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,
> 
> Thanks for your explanation. I begin to see some light regarding the 
> construction of the CESR string.
> 
> I have a minor edit suggestion for your registration, that would help 
> readers to more easily find the appropriate places in the CESR spec. 
> This refers to lines 84-86 in the application [1].
> 
> [[
> 
> Let's say we choose to use Blake3-256. The digest is then computed on 
> the above string and encoded in CESR format. This is the SAID of the 76- 
> character string as follows:
> 
> ENI2bDYghiu1KYYkFrPofH8tJ5tNiNt8WrTIc4s_5IIH
> 
> ]]
> 
> I suggest that if add a line or two about the EN...IH string along the 
> lines of „where the initial ‚E‘ signifies the use of Blake3-256 Digest 
> as specified in §11.4.2 of the CESR specification and the rest of the 
> string is the Blake3 digest of the string 
> ‚field_0_01234567############################################field_2_98765432‘“.
> 
> That would make it easier to understand for a casual reader not so 
> knowledgeable with CESR.
> 
> And, as said, this is a mere suggestion. I’d support the registration of 
> the namespace without this change.
> 
> [1] _https://github.com/trustoverip/kswg-said-urn-charter/blob/main/ 
> urn_application.txt <https://github.com/trustoverip/kswg-said-urn- 
> charter/blob/main/urn_application.txt>_
> 
> Best,
> 
> Lars
> 
> *Von:* Wenjing Chu [mailto:[email protected]]
> *Gesendet:* Montag, 2. Februar 2026 19:52
> *An:* Lars G. Svensson <[email protected]>
> *Cc:* [email protected]; [email protected]; 
> [email protected]; [email protected]; [email protected]
> *Betreff:* Re: [urn] Re: URN Namespace Registration for SAID (Self- 
> Addressing 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] 
> <mailto:[email protected]>_>
> *Date: *Monday, February 2, 2026 at 6:11 AM
> *To: *Wenjing Chu <[email protected] <mailto:[email protected]>_>
> *Cc: *[email protected] <mailto:[email protected]>_ <[email protected] 
> <mailto:[email protected]>_>, [email protected] 
> <mailto:[email protected]>_ <[email protected] <mailto:[email protected]>_>, [email protected] <mailto:[email protected]>_ <[email protected] <mailto:[email protected]>_>, [email protected] <mailto:[email protected]>_ <[email protected] <mailto:[email protected]>_>, [email protected] <mailto:[email protected]>_ <[email protected] <mailto:[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]

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