sidetree: Long form resolution returns id in did document with initial state

This is intentional, because if you are using an unachored DID and only include the short-form suffix of the ID in your resulting DID Document, there is a good chance a counter party could end up including the ID in a credential or other form of data that would subsequently be unresolvable, given it doesn’t contain the long-form data. The Sidetree reference and ION return a DID Doc with the short-form ID when it detects an ID is anchored.

@JaceHensley you might want to use did key, the structure of the sidetree spec has changed a lot since we released the element testnet…

• https://github.com/transmute-industries/did-key.js/tree/master/packages/secp256k1

I’m sorry in advance for the breaking changes we are gonna give you with element spec v0.1.0 conformance release.

@tplooker @peacekeeper @csuwildcat as discussed on id&d call today… the did document id MUST be a DID and NOT an DID_URL… this means we need to return initial state in resolver meta data, and drop the query parameters… essentially, exactly what tobias suggested…

{
   "@context":"https://www.w3.org/ns/did-resolution/v1",
   "didDocument":{
      "id":"id:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A",
      "@context":[
         "https://www.w3.org/ns/did/v1",
         {
            "@base":"did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A"
         }
      ]
   },
   "methodMetadata":{
      "recoveryCommitment":"EiDfGi474ij49Vq_yiKG1q8oC1jH_BFLfH27BIQKUnTBTw",
      "published": true,
      "initialState":"eyJkZWx0YV9oYXNoIjoiRWlDUlRKZ2Q0U0V2YUZDLW9fNUZjQnZJUkRtWF94Z3RLX3gwV0gtZXVhNGhrZyIsInJlY292ZXJ5X2NvbW1pdG1lbnQiOiJFaURmR2k0NzRpajQ5VnFfeWlLRzFxOG9DMWpIX0JGTGZIMjdCSVFLVW5UQlR3In0.eyJ1cGRhdGVfY29tbWl0bWVudCI6eyIwIjoxOCwiMSI6MzIsIjIiOjIyMywiMyI6MjYsIjQiOjQ2LCI1Ijo1OSwiNiI6MjI2LCI3Ijo0MCwiOCI6MjQ4LCI5IjoyNDUsIjEwIjo5MCwiMTEiOjE5MSwiMTIiOjIwMiwiMTMiOjM0LCIxNCI6MTM0LCIxNSI6MjE0LCIxNiI6MTc1LCIxNyI6NDAsIjE4IjoxMSwiMTkiOjg4LCIyMCI6MTk5LCIyMSI6MjUyLCIyMiI6MTcsIjIzIjo3NSwiMjQiOjEyNCwiMjUiOjEyNSwiMjYiOjE4NywiMjciOjQsIjI4IjoxMzIsIjI5IjoxMCwiMzAiOjgyLCIzMSI6MTE2LCIzMiI6MTkzLCIzMyI6Nzl9LCJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoielEzc2hta2VNZmh1RHdOOGExS3YiLCJ0eXBlIjoiU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOCIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6InNlY3AyNTZrMSIsIngiOiJhYTZhNDVhM1lnRW1sYks2cjVwYmlCcDhkV2RVZTZ2bUJsWWhIS2dhWGRRIiwieSI6InZPR1A2cVVZMUt3cFk3VFpENzI5c2p3S2d0b0hPZ1NyY1pHMmFUSExQYWsifSwicHVycG9zZSI6WyJnZW5lcmFsIl19XX19XX0"
   }
}

@JaceHensley as the subject of a DID if created a DID and I want someone to be able to resolve it prior to successful anchoring I am going to have to be responsible for that anyway in how I communicate my DID (i.e I will need to append the initial-state param), I don’t see how it being appended to the id element in the did document facilitates this?

Put another way, as a client performing resolution I had to have the initial state to construct the resolution request in first place, so what utility does it serve sending it back to me in all areas of the did document where the id is quoted.

Following that logic then the create operation response for a sidetree node should then also return a full didDocument including the initial state appended in the id element (just to be clear I’m not proposing this as a solution just using it to highlight the inconsistency in behaviour)

Just to clarify the behaviour in case there is confusion, if I launched the following request at a sidetree node

curl http://localhost:3000/identifiers/did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A

Even if the node has a pending registration request (i.e its waiting to close the batch and anchor the DID did:ion:test:EiC0wVS3K9VLv-XZVL55i8Y4d1Hk1kJpeckfDXIu0nM17A), the sidetree node will return a 404 until the anchoring is successful. So in short unless I have constructed a resolution request that features initial state param I will not get back an initial state did document.

To further the point as to why it would be cleaner to shift this information into the method metadata, how am I as a resolver client able to quickly discern if a did has now been registered? Currently if I had launched a resolution request that featured the initial-state to guarantee some form of resolution, the only way I would know the did is now anchored is by inspecting the id of the did document and parsing to determine whether the initial-state param is present? Would it not be cleaner for a client to just check response.methodMetadata.anchored?

This is a dupe of https://github.com/decentralized-identity/sidetree/issues/777

though your code examples are better.