Summary

  • RFC 6920, published in April 2013, defined Named Information (ni) names that identify digital objects through a hash algorithm and digest. Two such names designate the same object when algorithm, length and digest match, even if their optional authorities differ.
  • An ni name can be mapped to an HTTP(S) /.well-known/ni/ URL to ask a host for the object. The host helps locate candidate bytes; the digest lets a checking client decide whether those bytes match the name. IANA records the algorithm names and lengths used by the scheme.
  • The specification allows an application to choose whether to check the name–data binding. Its security model starts with a name whose own source must be trusted. A dated retrieval trace and a client digest check would establish how a particular deployment used the scheme.

A place to ask is not the thing being asked for

The ordinary web URL carries a host, a path and a scheme. The host gives the client somewhere to make the request. That arrangement is powerful because a server can replace the bytes at a path without changing the address printed on every link to it. It is also a poor answer to a different question: whether a file retrieved today is exactly the file someone meant when they shared the link.

Hash outputs had long appeared in identifiers, but different systems wrote them into names in incompatible ways. RFC 6920 standardized a common form. A Named Information URI can look like ni:///sha-256; followed by the unpadded base64url encoding of a digest. The algorithm is explicit. The digest is a value computed from the object; by default, the input is the bytes expected on retrieval. Applications using different inputs have to specify their own rules.

This changed the question the name answers. A location-based address says where to try. The ni name says what byte string a checking application expects. If a server moves the object, another server can serve the same bytes under the same content name. If a server swaps the bytes, the computed digest changes and the old name stops matching. The publisher of a URL may change a path's contents; the publisher of a hash name must issue a new name for changed bytes.

RFC 6920 makes that separation unusually strict. When comparing two names, an implementation considers the digest algorithm and value, including the indicated length. It ignores other fields such as the optional authority and query parameters. An ni URI with a host and an ni URI without one can point to the same object. Two different hosts can offer the same object. The host is a clue for retrieval, not a vote on the object's identity.

The address book returned at delivery time

Taking the host out of the identity test did not eliminate the need for a host. RFC 6920 defined a mapping from the ni name to an HTTP or HTTPS URL under /.well-known/ni/. If the ni name supplies an authority, that authority supplies the host in the mapped URL. If it supplies none, an application may choose one from context. The client can ask that host for the object and then check what arrived.

The mapped URL can redirect. That is ordinary web delivery, with a new constraint on the result: the bytes eventually received must be tested against the named digest if the application wants the integrity binding. The RFC states that the mapped HTTP location offers no guarantee that the object will be available there. A correct fingerprint attached to an empty cabinet is still a failed fetch.

This is the control split at the heart of the design. Whoever gives the client the ni name chooses the expected bytes. Whoever runs the HTTP host chooses whether and how to serve candidate bytes. The client chooses whether to verify the match. An operator can change a server, cache or redirect without changing the identity of the object, provided the new path still produces matching bytes. The digest protects the identity test; the running distribution system carries the object.

The scheme also had to fit different environments. RFC 6920 described a compact binary form for protocols that could not afford a long textual URI and a nih form intended to be spoken more reliably, using hexadecimal characters and a check digit. Those formats are different ways to communicate the same content-derived name. They were not alternative delivery networks. The document's use of an HTTP mapping shows how much practical reach still depended on an addressable service.

The ledger lists algorithms, not copies of files

A hash name needs an agreed way to say which function produced the value. The IANA Named Information registry lists algorithm names, lengths, references and the ct content-type parameter. RFC 6920 required support for full SHA-256 and allowed other registered choices, including explicitly named truncations. Shortening a digest changes the collision risk. The name tells the verifier which length it is handling; an abbreviated value cannot masquerade as the full one.

The registry's job is narrow. It coordinates names for hash functions and parameters so two implementations can parse the same identifier. It stores neither the digital object nor a list of hosts willing to provide it. An IANA row for sha-256 proves that implementations have a shared spelling. It does not prove that a file exists, remains online or has been fetched and checked by any client.

That narrowness protects a useful distinction. A central register can specify how an identity is written without becoming the owner of every object bearing that identity. The IETF standardized the syntax and the comparison rule. A publisher and distributor still have to run the servers, and a client still has to perform the check. A single registry record cannot substitute for those operations.

The fingerprint's source matters

RFC 6920's security section gives the hard limit: the hash can bind a name to returned bytes only as strongly as the client trusts the name it received. An attacker who gives a reader both a malicious file and its matching digest has produced a perfectly consistent pair. The digest verifies agreement between two pieces of data; it does not identify the person who chose them. The origin and delivery of the expected name remain part of the trust story.

The specification also permits applications to process ni names without checking the content binding. A standardized syntax therefore creates an opportunity to verify, not a universal guarantee that every client does so. For a named deployment, the decisive evidence is a trace showing the name received from a trusted source, the retrieval path, the bytes returned and the digest comparison the client actually made.

Even a strong name does not hide the object. RFC 6920 notes that a published digest may let someone discover a likely file through a repository or by guessing a low-variation object and hashing the guess. The IANA registry includes named truncation lengths for contexts that can tolerate different collision odds; a shorter digest carries a smaller security margin. Integrity, availability and secrecy travel on separate rails.

The official RFC and registry establish what the name means and how it is formatted. They do not show that a particular archive, browser or distribution service used ni in production. A dated client and server trace would change that finding. The historical achievement is still concrete: the file could keep one identity while its delivery address changed, and a client had a precise test for the bytes at the end of the route.