Re: Registration request for urn:eris: namespace

Hello Endo,

Thank you for submitting this namespace registration request. Other 
reviewers might be more insightful than I am, but I've provided some 
comments and suggestions inline.

On 9/16/23 3:37 AM, Endo Renberg wrote:
> Namespace Identifier:  ERIS
> Version:  1
> Date:  2023-09-16
> Registrant:  Endo Renberg <[email protected]>
> 
> 
> Purpose:  ERIS URNs identify and verify immutable data.

This description is rather terse. Indeed, the sentence "ERIS URNs 
identify and verify immutable data" would be almost as meaningful if we 
removed the word "ERIS". Visiting https://eris.codeberg.page/spec/ we 
learn that:

###

ERIS is an encoding of arbitrary content into a set of uniformly sized, 
encrypted and content-addressed blocks as well as a short identifier 
that can be encoded as an URN.

###

and:

###

[N]aive content-addressing has certain drawbacks:

- Large content is stored as a large chunk of data. In order to optimize 
storage and network operations it is better to split up content into 
smaller uniformly sized blocks and reassemble blocks when needed.

- Unencrypted: Content is readable by all peers involved in 
transporting, caching and storing content.

ERIS addresses these issues by splitting content into small uniformly 
sized and encrypted blocks. These blocks can be reassembled to the 
original content only with access to a short read capability, which can 
be encoded as an URN.

###

I suggest that you provide slightly more detail in the Purpose section.

> ERIS URNs are application, location, and protocol independent and may be
> created by anyone for any purpose which requires immutable data.
> 
> These URNs may be conveyed in URLs using the "URN to Resource" method
> described in RFC2169 (https://datatracker.ietf.org/doc/html/rfc2169).

First, using RFC 2169 seems like a resolution method (that document 
"specifies the 'THTTP' resolution protocol") and thus this sentence 
might belong in the Resolution section of the registration request.

Second, given that (a) RFC 2169 was Experimental and (b) HTTP 1.0 and 
1.1 have been superseded by more modern and secure versions of HTTP, is 
this resolution method truly advisable at this time?

> Software may resolve ERIS URNs to content by use of dedicated ERIS services
> or by embedding an ERIS software library, both of which are freely
> available.
> 
> 
> Syntax:
> 
> BASE32    =   A-Z / 2-7
> ERIS-URN  =  "urn:eris:" 106(BASE32)
> 
> The semantics of the base32 digits is described in
> https://eris.codeberg.page/spec/#section-2.6.

A reference to RFC 4648 might be appropriate regarding the definition of 
base32.

> The use of r/q/f components in URNs is application specific and is neither
> defined or prohibited.

Is that helpful? In the context of ERIS as a simple block-encoding 
method (and quoting descriptions from RFC 8141), I wonder about the 
purpose, even at a high level, of:

- "passing parameters to a URN resolution service" via the r-component?

- "passing parameters to either the named resource or a system that can 
supply the requested service" via the q-component?

- specifying "a location within, or region of, the named resource" via 
the f-component?

> Assignment:  ERIS operates independently of any authority. Data is
> assigned an ERIS URN by chunking it by one of two block-sizes and using
> a convergent (deterministic) or unique block encoding. This results in two
> possible convergent URNs for any given data or an unlimited number of unique
> URNs.

By "data" here do you mean a particular block of data or the content 
that is encoded into blocks? I suspect the former, but it would be good 
to ensure consistency with the terminology in the ERIS spec. (Strictly 
speaking, the URN seems to identify a "read capability", but I'm not 
sure how that differs from the content that is encoded into blocks.)

> Security and Privacy:  ERIS URNs identify data independently of location so
> knowledge of a URN must be assumed to be sufficient authorization to access
> the data that it refers to. 

That feels like a slightly suboptimal authorization model, but the URN 
review team isn't here to critique underlying protocols.

> This behavior also permits the so-called
> "Confirmation of A File" attack which may be partially mitigated by
> creating URNs using unique encodings.

What is meant here by "unique encodings"? Does that mean an encoding 
other than ERIS?

> Interoperability:  An ERIS namespace is not know to be in use elsewhere and
> the ERIS URN is designed to be highly interoperable. The interpretation of
> base32 data within the URN is constrained and non-extensible.

s/know/known/

> Resolution:  An ERIS URN may be resolved to content by standalone services
> or embedded software libraries. No organization is responsible for hosting
> and resolving ERIS encoded data.

What does resolution mean in the context of ERIS as (seemingly) a fully 
decentralized system? Is the read-capability URN resolved to the content 
itself? How does that interact with the encryption properties of ERIS?

> Documentation:  http://purl.org/eris

Pointing to https://eris.codeberg.page/spec/ might be better if that is 
expected to be the longer-lived URI.

BTW, do you also plan to register the blake2b namespace identifier 
mentioned in Section 2.7.1 of the ERIS spec?

Thanks,

Peter