Element Contract is ambiguous when we have more than 1 / many networks

[OR13]

We need a naming convention that takes into account the following:

• Contract Type (Simple / Staking)
• Contract Address
• Network Type (Ropsten / Mainnet)

today, we have did:elem:ropsten, where (elem:ropsten) -> (simple contract on ropsten address deployed by us)...

I'd like to make this more configurable, and for DIF to maintain a table of the mappings / did method names, etc...

@Therecanbeonlyone1969 @gjgd @awoie @mirceanis what are your thoughts on this?

[OR13]

@JaceHensley @tplooker @kdenhartog interested in your thoughts on this as well, I'm very open to a naming structure for Ethereum / element derived Sidetree methods that is configurable / inclusive.... and while we would probably still like did:elem to mean something... I am open to suggestions for more flexibility.

one option would be to also use caip-10 https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md#test-cases

to register a blockchainAccountId for "friendly method name", and manage the registry in DIF....

technically, did:elem:ropsten could be isomorphic to did:elem:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1:.....

or in easy to read form: did:METHOD:CAIP-10:UniqueSuffix

@peacekeeper ^ does this obviously break ABNF rules?

[mirceanis]

we have a similar problem in did:ethr where the solution is to embed the network name or chainID in the id:
did:ethr:rinkeby:0xblabla or did:ethr:0x4:0xblabla

It is not a perfect solution as it requires the implementer to correctly map the network and there is no discussion about contract address.

[OR13]

@mirceanis yes, we copied you :) wondering in world where there are many did:ethr and did:elem on ropsten, managed by different companies.... if we should try and upgrade this sooner rather than later.

[csuwildcat]

"DIF to maintain a table of the mappings / did method names" - what are you thinking?

[gjgd]

What if the contract address were a specificity of the did method?

In the same way that we don't specify did:elem:ethereum:ipfs because those informations are included in the name "Element", I suggest we don't specify contract address in the identifier.

With this naming convention, Element would be an implementation of Sidetree that uses IPFS, Ethereum at a certain address, with a specific set of parameters (eg maxOperationsPerBatch, batchingIntervalInSeconds, etc...à

With this naming convention, another Sidetree method implementer choosing to use Ethereum and IPFS on a different contract address would have to come up with a different name than "element".

[csuwildcat]

With this naming convention, another Sidetree method implementer choosing to use Ethereum and IPFS on a different contract address would have to come up with a different name than "element".

I really think they should have to do that anyway, and we should really push back against folks reusing method names as if they can be different flavors.

[Therecanbeonlyone1969]

With this naming convention, another Sidetree method implementer choosing to use Ethereum and IPFS on a different contract address would have to come up with a different name than "element".

I really think they should have to do that anyway, and we should really push back against folks reusing method names as if they can be different flavors.

I agree -- element is a sidetree implementation, and a particular implementation of element will have a particular contract address. I would suggest we look at this from a workflow perspective: when a user calls the did-resolver with did:: --> do we require for the did resolver to maintain a mapping of did-doc anchoring service provider APIs for a given did method such that the resolver would then have to call e.g. 10 APIs, and see which service replies with the did doc or do we require the user to specify not only did:: but also the provider, either its API or identifying metadata that allows the resolver to identify ONE api to call? The latter would not be a problem if the user is the DID owner, but if you call the resolver as part of DIDComm for example it becomes an issue since the user only has did::. Imho, this means we either embed the required metadata to identify the provider API through a DID extension or force the resolver to maintain and update mappings. From a simplicity and UX point of view, I would unload the work on the resolver. But I am just raising the question of UX in this context. @csuwildcat @OR13 @gjgd @mirceanis

[OR13]

I'm not opposed to did:elem or did:ethr supporting CAIP-10 aliases for DIDs... IF the actual method code is being used.... however... there is not way to actually FORCE that... so it is a security consideration.

Here is the beginning of one such table

DID Method	Verifiable Data Registry	DID Method Spec
did:elem:ropsten	0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1	element-did.com/spec
did:ethr:rinkeby	0xdca7ef03e98e0dc2b855be647c39abe984fcf21b@eip155:4	uport.me/spec

[OR13]

Consider also... there will be private networks that use element / ethr dids....

[bumblefudge]

^ Some already are!

[OR13]

Cross linking: https://github.com/w3c/did-spec-registries/issues/102