Add did:earth

[ig-shaun]

Initial commit for the Interchain Identifier Specification (under development) from the Interchain Foundation Earth Program.
The draft specification can be found at https://github.com/EarthProgram/Identifiers/blob/main/interchain-identifiers-specification.md

---

Preview | Diff

[msporny]

This URL is 404'ing for me. The w3id.org URL redirect needs to be updated to point to: https://github.com/EarthProgram/Identifiers/blob/main/interchain-identifiers-specification.md

[msporny]

The draft specification can be found at https://github.com/EarthProgram/Identifiers/blob/main/interchain-identifiers-specification.md

There is a good amount of detail in the specification wrt. philosophy and architecture -- that's great.

The specification has the requisite section for DID Syntax.

The specification doesn't have clear sections outlining how one would Create, Read, Update, and Deactivate DIDs. I had to skim the specification to try and understand how that might happen, and I do understand that the details are left to other DID Methods, but there is an expectation that each DID Method specification has clear sections on Create, Read, Update, and Deactivate.

The specification is missing the Security Considerations and Privacy Considerations section. Please add those sections.

Please add the required sections (or point to them using links in a response).

I should also warn you that we're changing the repository's registration submission format in three days, which unfortunately you're going to be caught up in. It's the only time we've done that in the last 5 years, so apologies... I'm happy to help you convert to the new format (it's not a difficult process at all), or, once we get this approved, I'm happy to register did:earth for you via the new process. Just a heads up, hope you're well @ig-shaun. :)

[kdenhartog]

I just spent a bit of time looking through this method and at this point it's not clear to me how I should be implementing this spec. I know based on the detail and philosophy (as well as having spoken with @ig-shaun at RWoT in the past) that the intent of this method is going in the right direction. Here's a few points below that I see issues with at this point:

1. Looks like the method name needs to be properly defined as well. Right now the ABNF is an exact match to what's in the DID-Core specification which doesn't specify any specific method name character set and instead allows for any method name to be used in which case this method would encounter a name collision with other methods.

2. There also appears to be a conflict between the terminology which defines that the fragment query parameter is meant to be reserved for references to the subject and are therefore not supposed to be used to identify web resources. However, from the examples it appears that the fragment usage in the examples the # is being used to identify particular keys within the did document where are tangible web resources. I think this would need to be clarified further as to how to delineate between a resource on the web, a resource in the did document, and a physical world entity associated with the subject or you're likely to still encounter the HTTP Range 14 problem.

3. It's also worth mentioning that while the proof type values ("hash" | "hashgraph" | "hashset") are all valid these are likely to run into name collisions in the future. I'd suggest either qualifying these further with the use of iid: or go more along the route of keeping this proof object in line with the LDI work where a proper suite is defined for this and making it more generalized for a variety of signed json-ld documents.

4. The JSON-LD in example 1 is going to drop the publicKeyMultibase property in a JSON-LD processor because the term is not defined. You'd need to add the proper suite here to make this work. That should be https://www.w3id.org/security/suites/ed25519-2020/v1.

5. The JSON-LD in example 2 is not clear to me why the https://internft.org/ns/iid/v1 is being included. From the looks of it that link also returns a 404 error so I think it could be dropped by a JSON-LD processor. From reading on, it seems like the context is supposed to be an indicator that this is a specific type of did document, but I wouldn't recommend this path of using context properties to identify it. Rather, I think it would make more sense to leverage a type property within the base layer of the did document to identify that this is specifically an IID document.

6. The linkedResource term in Example 3 is going to be completely dropped at this point by a JSON-LD processor because the term is not defined within a context anywhere.

7. It would be good to take the note below example 3 where herd privacy is discussed as optional but should be used to a privacy considerations section and further expanded on. It's not clear to me what aspects are providing the herd privacy to me at this point.

8. The requirements are not clear to me about what must be done to make some of these things happen. For example, in the second point it says "... MUST be able to refer to any asset on any chain, on any network, on any fork..." but it doesn't make clear how this is to be done in an interoperable way. Is the method specific identifier supposed to be used to have sub networks for this and if so how is the read operation supposed to perform differently for the different sub networks that get used since it's not possible to follow the same algorithm for all chains networks and forks as far as I'm aware.

9. Requirement 3 points out that the JSON-LD representation MUST be used, but I don't see how that's possible at this point since some of the commonly used terms are getting dropped in the examples above.

10. It's not clear to me if this is a meta method specification that's supposed to define how other IID method specifications should be defined or if this is a specific method spec at this point.

11. You probably don't want to be burying normative statements like "To achieve this, IID methods SHOULD use content-derived identifiers and MAY use content-derived addressing systems, in which the cryptographic hash of a linked resource is used to unambiguously verify the resource." below the documents reference section.

All in all, I don't think this spec is ready yet and I think we'd be doing a disservice to allow this method to be registered until at least the bare minimum did-core requirements are met. Once they're met I think it's acceptable to register the method at least but as I point out above just meeting those bare minimum requirements won't necessarily make it any easier to implement and so you should look to making sure all the details around JSON-LD as well as normative statements are clear to make it easier for an implementer to develop interoperable implementation as well.

[msporny]

I just spent a bit of time looking through this method

Really excellent analysis, @kdenhartog -- we have an opening for a did-spec-registries reviewer since our last one kicked the bucket (but we're pretty sure they were just faking it). Interested? We can spray down the uniform and have it ready by tomorrow. The pay sucks, there are no benefits, the customers are always mad, and it will almost certainly lead to premature hair loss (everywhere)... whaddya say?!

[jandrieu]

Agreed. As a contributor to the work, I've spoken with @ig-shaun. The current spec really was meant as a family of DIDs, akin to Sidetree. What we need is the specific profile of that IID spec for did:earth.

That said, thanks for the analysis, Kyle. Your points are spot on and will be useful as I work with Shaun to get a proper spec drafted.

[kdenhartog]

I just spent a bit of time looking through this method

Really excellent analysis, @kdenhartog -- we have an opening for a did-spec-registries reviewer since our last one kicked the bucket (but we're pretty sure they were just faking it). Interested? We can spray down the uniform and have it ready by tomorrow. The pay sucks, there are no benefits, the customers are always mad, and it will almost certainly lead to premature hair loss (everywhere)... whaddya say?!

Yeah I think that's probably the best way to bring my expertise in to help lift all methods together. Sign me up and I'll do my best to keep providing these types of analysis to help make better did methods.

[msporny]

Sign me up and I'll do my best to keep providing these types of analysis to help make better did methods.

Great, thank you @kdenhartog !

@brentzundel @burnburn I'm nominating @kdenhartog as a DID Spec Registries Editor, looks like he's amenable to the job (see above). Request to bring this up on the next DID WG call. /cc @OR13 @mprorock

[ig-shaun]

Thanks for all your feedback and engagement on this. We wanted to get a placeholder in on the namespace before I made a public presentation about the IID developments in Lisbon.

Now working together with Joe to get this in shape as a properly specified method, in the required format, before we ask for this to be formalised in the registry.

[OR13]

I would love to have @kdenhartog as an editor of the did spec registries.

[OR13]

did method spec is currently 404.

[peacekeeper]

This looks interesting, but I'm not sure if what it defines is actually a DID method.

did:earth: isn't mentioned anywhere in the specification?

[mprorock]

per discussion on call - @ig-shaun would you mind closing, and then opening a PR once a DID spec is in place for review

[iherman]

The issue was discussed in a meeting on 2021-12-07

• no resolutions were taken

View the transcript

4.2. Add did:earth (pr did-spec-registries#364)

See github pull request did-spec-registries#364.

Michael Prorock: next PR same issue, they need to be reminded to update the PR.
… correct the 404, remove conflicts..

Manu Sporny: I think we should ask them to close this PR.
… my understanding is that they wanted to register this, but they don't have a spec, so they should raise the PR when they have one..

Michael Prorock: I will ping them.