[urn] Re: URN Namespace Registration for SAID (Self-Addres sing Identifiers)
Peter Saint-Andre <[email protected]> Thu, 12 Mar 2026 16:57:42 -0600
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <[email protected]> |
Excellent. Let's see what Dale and Lars have to say. :-) On 3/12/26 4:17 PM, Wenjing Chu wrote: > Thanks Peter! I've updated it with these two revisions and changed the > version to 0.4 - so we can set to 1 when approved. > > 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> > > Wenjing > > > *From: *Peter Saint-Andre <[email protected]> > *Date: *Thursday, March 12, 2026 at 2:27 PM > *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: *Re: [urn] Re: URN Namespace Registration for SAID (Self- > Addressing 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://nam11.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgithub.com%2Ftrustoverip%2Fkswg-said-urn- > charter%2Fblob%2Fmain%2F&data=05%7C02%7Cwchu%40futurewei.com%7Cd463cec50d3a4533637f08de807e2f08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639089476669741227%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iw8q%2Fz0GZm0b6YxTPWa%2BJ8QhYIU8%2B3kuDxRRgzn41qA%3D&reserved=0 <https://github.com/trustoverip/kswg-said-urn-charter/blob/main/> > > urn_application.txt <https://nam11.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgithub.com%2Ftrustoverip%2Fkswg-said-urn- > &data=05%7C02%7Cwchu%40futurewei.com%7Cd463cec50d3a4533637f08de807e2f08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639089476669766441%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=76ZFIvp4exI0TzyrJcO5A8UMVS%2FPwCAbUuh9LjcE8mc%3D&reserved=0 > > 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://nam11.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgithub.com%2Ftrustoverip%2Fkswg-said-urn- > charter%2Fblob%2Fmain%2F&data=05%7C02%7Cwchu%40futurewei.com%7Cd463cec50d3a4533637f08de807e2f08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639089476669786499%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ISBZyTZjVWh9lmmi24SLsPEkWsokbXHCz8cEjSTG0oE%3D&reserved=0 > > urn_application.txt <https://nam11.safelinks.protection.outlook.com/? > url=https%3A%2F%2Fgithub.com%2Ftrustoverip%2Fkswg-said-urn- > &data=05%7C02%7Cwchu%40futurewei.com%7Cd463cec50d3a4533637f08de807e2f08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639089476669806360%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zb8Ev6s93B7J2N9J2KVKT476t56OYkfloQ4jDUY5WpY%3D&reserved=0 > > charter/blob/main/urn_application.txt>_ > > > > Best, > > > > Lars > > > > *Von:* Wenjing Chu [mailto:[email protected] > <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]>_ <mailto:[email protected]>_>> > > *Date: *Monday, February 2, 2026 at 6:11 AM > > *To: *Wenjing Chu <[email protected] <mailto:[email protected]>_ > <mailto:[email protected]>_>> > > *Cc: *[email protected] <mailto:[email protected] > <mailto:[email protected]>>_ <[email protected] > > <mailto:[email protected]>_ <mailto:[email protected]>_>>, > [email protected] > > <mailto:[email protected] > <mailto:[email protected]>>_ <[email protected] <mailto:[email protected]>_ <mailto:[email protected]>_>>, [email protected] <mailto:[email protected] <mailto:[email protected]>>_ <[email protected] <mailto:[email protected]>_ <mailto:[email protected]>_>>, [email protected] <mailto:[email protected] <mailto:[email protected]>>_ <[email protected] <mailto:[email protected]>_ <mailto:[email protected]>_>>, [email protected] <mailto:[email protected] <mailto:[email protected]>>_ <[email protected] <mailto:[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:// > nam11.safelinks.protection.outlook.com/? > url=https%3A%2F%2Ftrustoverip.github.io%2Fkswg-cesr- > &data=05%7C02%7Cwchu%40futurewei.com%7Cd463cec50d3a4533637f08de807e2f08%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639089476669826491%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EDMJbzFCAPyHq%2FfQGJTt7ql4bKRB5PgtzI04rdZqxuE%3D&reserved=0 > > 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]