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

[Wenjing Chu <[e-mail]>]

Thank you again, Dale, and earlier Ted, for your very helpful comments.
Sorry for my delay in responding. I hope I captured all the information I received and edited the application to address them. If I missed anything still, please let me know - I promise to follow up a lot quicker than last time. Thank you!

The new application is here: https://github.com/trustoverip/kswg-said-urn-charter/blob/main/urn_application.txt

I’m also attaching a copy in this email.

Changes included:

  *
ANBF syntax updated to reflect its relationship with CESR code and encoding more accurately
  *
CESR encoding and the SAID derivation procedure summarized in the document
  *
Examples extended both in terms of data format examples and digest functions
  *
Added text for security and privacy considerations
  *
Interoperability section revised
  *
Other general improvements and edits etc.

Best regards,
Wenjing



From: Wenjing Chu <[e-mail]>
Date: Friday, November 21, 2025 at 10:51 AM
To: Dale R. Worley <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [urn] Re: URN Namespace Registration for SAID (Self-Addressing Identifiers)

Thank you, Dale! Received both of your emails. I will use this reply to keep the thread going.

I will probably need a few days to go over many points you raised here.

But first, thanks to the suggestions about the ABNF section. I was a bit reluctant as I was including that section in the first place, precisely because of the issues you raised here. It is not the ABNF in a typical sense but rather describing the effect of a SAID calculation. I agree that your suggestion is a good way to resolve this issue.

Will follow up with a revised registration request.

Best,
Wenjing


From: Dale R. Worley <[e-mail]>
Date: Wednesday, November 19, 2025 at 7:26 PM
To: Wenjing Chu <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [urn] Re: URN Namespace Registration for SAID (Self-Addressing Identifiers)
My apologies for neglecting this registration request for far too long.

Reading the submitted registration again, and addressing points as I run
into them:

The "Purpose" section reads very well to me.

As I noted before, I think the "Syntax" section should emphasize the
ABNF (as that is unambiguous and universally understood) and treat the
text parts as explanation, annotation, etc. of the ABNF.

Note that as the ABNF is written, an SAID URN must start with one of
exactly nine prefixes:  E, F, G, H, I, 0D, 0E, 0F, 0G.  You comment that
it would be useful to allow extensibility.  As the ABNF is stated,
allowing other prefixes would require an amendment to the registration.
And clearly, adding a digest algorithm that has a different length
output would require revising the ABNF.  An alternative would be for the
registration to say that an SAID URN must start with a prefix listed in
Table [whatever] of the CESR specification and that it contains as many
base64urlsafe characters as needed to encode the algorithm's output.

Regarding the table in section 11.4.2 of the CESR specification, I found
it hard to read.  In particular, it seems to contain information for a
variety of different codes that have different uses, all listed as if
they're part of the same class of codes.  The classes that I could
identify include "Count Codes", "Universal Genus Version Codes",
"Universal Count Codes that allow genus/version override", "Genus
Specific Count Codes", "Operation Codes", "Primitive Matter Codes",
"Basic One Character Codes", "Basic Two Character Codes".  This is quite
confusing for the uninitiated; naively I would expect each class of code
to be in a separate table, headed by a short summary of what the class
of codes is for.  But if you want the URN specification to reference an
extensible list of prefixes in the table, it's not clear how you would
write text that specifies the subset of all those codes which are
intended to be valid prefixes for SAID URNs.

There is also an interesting point about extensibility:  One has to know
how to calculate the desired hash function to create a CESR object, and
thus its SAID URN.  But one does not need to understand the hash
function to catalog the fact that "object [whatever] is named by SAID
URN [whatever]".  It appears to me that given a CESR object, one can
extract its SAID from the object itself, even if one does not know how
to calculate/verify its SAID.  So applications that interpret SAID URNs
can be extensible to handle URNs naming hash functions that they
themselves do not understand.  This might be worth mentioning in the
registration, perhaps in the form "Applications that input SAID URNs
must be prepared to handle URNs generated using hash functions that they
do not understand."

    Examples:

      - `urn:said:E8wYuBjhslETYaLZcxMkWrhVbMcA8RS1pKYl7nJ77ntA`
      - `urn:said:EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ`

    The above examples are 44 characters long in text representation,
    where `E` indicates Blake3-256 digest and the remaining 43 characters
    encode 256 bit digest. Additional digest functions are listed in CESR
    2.0, Section 11.4.2.

As I noted before, it would be beneficial to add examples that use other
hashes, and in particular, one with a different hash length.

The sentence "Additional digest functions are listed ..." might be
misinterpreted to mean that all digest functions listed in 11.4.2 are
valid, whereas only 9 are.  I would say something like

    The one-char-code and two-char-code prefixes specify the digest
    algorithm used to generate the digest according to the table in CESR 2.0
    section 11.4.2.  In the above examples, the initial `E' indicates the
    Blake3-256 digest algorithm.  [similarly for other prefixes used in
    the examples]

It is not clear to me how much of the processing in CESR we would want
in the registration.  But it seems to me we want the "Assignment" section
to make the following points:

- We want to say that the SAID strings are *generated from* the digital
  assets that they describe.  This isn't exactly the same as
  "self-assigned" because whoever is doing the work doesn't get to
  *choose* what the SAID is; the SAID is determined by the asset.

    To illustrate, here is an example of how the derivation works (from
    CESR 2.0, Section 11.6):

    Suppose the initial value of Python dict data structure is as follows:
    {
        "said": "",
        "first": "Sue",
        "last": "Smith",
        "role": "Founder"
    }

- We need some clarity as to what sort of digital assets can have SAID
  strings.  The one example presented is a Python dict containing one
  member "said", whose value will ultimately be the SAID string.  But
  it's unclear what the class of assets is intended to be.  It seems
  likely that there are a variety of "formats" of asset but each format
  has a canonical place inside it into which the SAID string will be
  copied once it is computed. ... But we need the registration to
  clearly describe the class of resources which can be named with the
  URNs.

  Let me expand on that:  It needs to be clear what resource (or set of
  "equivalent" resources) each URN names.

- The description mentions "consistent serialization" several times, but
  most of them seem to me to add complexity without adding clarity.
  Clearly, if you're going to hash a data structure, you need some sort
  of consistent serialization, so the reader doesn't need to be told
  that.  But since the registration doesn't describe *what* the
  serialization scheme is, why mention it?

    If we choose the 44 CESR character Blake3-256 digest for SAID
    derivation and use JSON serialization, the first of the derivation
    procedure is to insert the `#` character in place of the future SAID
    string:
    {
        "said": "############################################",
        "first": "Sue",
        "last": "Smith",
        "role": "Founder"
    }

- For exactness, you want to say "insert a number of `#' characters in
  place of the future SAID string, where the number (44) is the sum of the
  length of the digest's prefix `E' (1) plus the number base64urlsafe
  characters that will be used to encode the digest (43)".

- BTW, if the digital asset is a "binary" object, is the SAID string
  inserted into it in the same way, that is, base64urlsafe encoded?  If
  it is inserted in binary, it's probably worth warning that for some
  assets, the SAID string inserted into the asset is different from the
  one in the URN.

    For consistent serialization, we remove all extra white space:
    {"said":"############################################","first":"Sue","last":"Smith","role":"Founder"}

- This is clear.  And it is an indirect reference to the fact that
  consistent serialization is needed and implies that the CESR standard
  tells how to do that.

    The URN for the above data representation is:
    `urn:said:EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ`

- I think you want some more detail:  The SAID string consists of the
  code for the digest algorithm, `E', followed by the base64urlsafe
  representation of the digest value of the serialization,
  `JymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJe'.

    The URN for the above data representation is:
    `urn:said:EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ`

    Now, the Python data structure may be updated to:
    {
        "said": "EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ",
        "first": "Sue",
        "last": "Smith",
        "role": "Founder"
    }

- This needs some more clarity.  As far as I can tell, the URN is for the
  *digital asset*, and the updated Python data structure is what the user
  thinks of -- and stores and transmits -- as the digital asset.  "the
  above data representation" seems to unnecessarily add complexity, as
  the URN is *for* the Python data structure.

    It is important to note that verification of SAID (therefore
    `urn:said`) must be performed on the consistent serialization format
    of the digital asset.

- This seems to be unnecessary.  Obviously, to verify an SAID, one needs
  to repeat the computation of it, and that has the same serialization
  requirements as the initial computation.

    In addition, the use of CESR encoding allows
    lossless transformation between binary and text domains. This property
    is useful in digital assets which may be most optimally represented in
    binary or serialization schemes such as CBOR.

It seems to me that this could be omitted.  As written, it's not clear
what it really means.  To make it clear, there would have to be some
background regarding what the "binary and text domains" are.  And there
is the implication that SAID is only applicable to digital assets which
somehow have both text and binary representations, which would need to
be part of the specification of what the applicable class of assets is.

    Adopters MAY consider narrowing selections of digest functions to
    reduce complexity and improve interoperability with some cost in
    flexibility.

This seems to me to be a bad idea.  There's no problem with an
application that can only *generate* one digest function.  But if an
application wishes to *verify* SAIDs, then if it does not compute all of
the specified digest functions, its interoperability is reduced.

Dale