[urn] URN Namespace Registration for SAID (Self-Addressing I dentifiers)

Namespace Registration for Self-Addressing Identifiers (SAID)

Namespace Identifier:  said

Version:  1

Date:  2025-09-25

Registrant: Sam Smith, Wenjing Chu, Carly Huitema
on behalf of ToIP (Trust over IP)
https://trustoverip.org/

Purpose: 

Self-Addressing Identifiers (SAIDs) are self-referential content-addressable identifiers based on CESR encoded cryptographic digest. This proposal defines a method to unambiguously identify digital assets that contain their SAIDs via their SAID identifiers in the urn:said namespace. Such urn:said identifiers can ease the ways of adopting SAIDs anywhere URNs are accepted and improve interoperability. These URNs are typically non-resolvable, serving as unique identifiers. However, optional mechanisms could be introduced in the future in addressing such requirements.

Syntax:

A `said` URN shall consist of two mandatory components in the following order, with `:` characters between each section.
 
  - URN identifier (`urn:said`): REQUIRED

  - SAID, in string representation as per Composable Event Streaming Representation (CESR) version 2.0, Section 11.6 and represented with Base64URLSafe alphabet of RFC 4648 (with the exception of `=` pad character which is not used in CESR). REQUIRED

The ABNF of an `said` URN MUST be as follows:

```ABNF
said-urn = "urn:said:" said

said = said-256 / said-512

; 256-bit SAIDs: 44 characters total (1 char code + 43 Base64URLSafe)
said-256 = one-char-code 43base64urlsafe
one-char-code = "E" / "F" / "G" / "H" / "I"

; 512-bit SAIDs: 88 characters total (2 char code + 86 Base64URLSafe)  
said-512 = two-char-code 86base64urlsafe
two-char-code = "0D" / "0E" / "0F" / "0G"

; Base64URLSafe characters (RFC 4648, excluding padding)
base64urlsafe = ALPHA / DIGIT / "-" / "_"
```

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.

Assignment: 

The SAID strings conforming to this scheme are self-assigned, based on the derivation of the SAID as per CESR version 2.0. The SAID strings are generated by a strong cryptogtaphic digest algorithm and the algorithm is self-encoded in the digest's CESR representation allowing flexibility to adopt future digest functions. The examples shown above, for instance, are generated using Blake3-256 digest and are 44 character long represented in CESR encoding.

The digital assets identified by an `urn:said` identifier must contain the SAID identifier in itself (i.e. self-referential). The SAID derivation procedure defined by CESR version 2.0 requires a consistent serialization scheme for the digital assets in order for correct representation and verification. In other words, SAID identifies the serialization of the digital assets where it is also contained.

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"
}

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 consistent serialization, we remove all extra white space:
{"said":"############################################","first":"Sue","last":"Smith","role":"Founder"}

Apply Blake3-256 digest algorithm to this representation, we obtain the SAID (encoded in CESR) string (in text format):
EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ

Now, replace the `#` spaceholder with the SAID string, the data asset with the SAID becomes:
{"said":"EJymtAC4piy_HkHWRs4JSRv0sb53MZJr8BQ4SMixXIVJ","first":"Sue","last":"Smith","role":"Founder"}

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"
}

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

Security and Privacy: 

No known security or privacy issues exist for this URN namespace.

Interoperability: 

A SAID string MUST be CESR encoded which self-identifies the digest algorithm used to generate it. This greatly enhances interoperability and future adaptability. 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.

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

Resolution:

These URNs are non-resolvable and serve as globally unique identifiers. In future, however, we may extend this scheme with optional information for easier resolution.

Documentation: 

- Composable Event Streaming Representation (CESR) version 2.0
- RFC 4648: The Base16, Base32, and Base64 Data Encodings, https://datatracker.ietf.org/doc/html/rfc4648

Additional Information:  NONE

Revision Information:  N/A