Finalize and implement the DID resolution spec with published field as resolution response

[thehenrytsai]

Assigning @csuwildcat to get the spec finalized before implementation can begin.

[kdenhartog]

@csuwildcat would it be possible to return transaction metadata as method metadata so that the integrity of the resolution can be validated without needing to launch a node? I would think this would be an optional parameter that could be passed in the URL.

Something like this for a potential strawman solution

GET /did:sidetree:exKwW0HjS5y4zBtJ7vYDwglYhtckdO15JDt1j5F5Q0A?options=base64URL<{"methodMetadata": true }> HTTP/1.1

And the resulting object could be:

{
  "didDocument": {
  "@context": "https://w3id.org/did/v1",
  "id": "did:sidetree:EiBJz4qd3Lvof3boqBQgzhMDYXWQ_wZs67jGiAhFCiQFjw",
  "publicKey": [{
    "id": "#key1",
    "type": "Secp256k1VerificationKey2018",
    "publicKeyHex": "029a4774d543094deaf342663ae672728e12f03b3b6d9816b0b79995fade0fab23"
  }],
  "service": [{
    "id": "IdentityHub",
    "type": "IdentityHub",
    "serviceEndpoint": {
      "@context": "schema.identity.foundation/hub",
      "@type": "UserServiceEndpoint",
      "instance": ["did:bar:456", "did:zaz:789"]
    }
  }]
},
"didMetadata": [{
  "header": "ewogICJvcGVyYXRpb24iOiAiY3JlYXRlIiwKICAia2lkIjogImtleTEiLAogICJhbGciOiAiRVMyNTZLIgp9",
  "payload": "eyJAY29udGV4dCI6Imh0dHBzOi8vdzNpZC5vcmcvZGlkL3YxIiwicHVibGljS2V5IjpbeyJpZCI6IiNrZXkxIiwidHlwZSI6IlNlY3AyNTZrMVZlcmlmaWNhdGlvbktleTIwMTgiLCJwdWJsaWNLZXlIZXgiOiIwMmY0OTgwMmZiM2UwOWM2ZGQ0M2YxOWFhNDEyOTNkMWUwZGFkMDQ0YjY4Y2Y4MWNmNzA3OTQ5OWVkZmQwYWE5ZjEifSx7ImlkIjoiI2tleTIiLCJ0eXBlIjoiUnNhVmVyaWZpY2F0aW9uS2V5MjAxOCIsInB1YmxpY0tleVBlbSI6Ii0tLS0tQkVHSU4gUFVCTElDIEtFWS4yLkVORCBQVUJMSUMgS0VZLS0tLS0ifV0sInNlcnZpY2UiOlt7InR5cGUiOiJJZGVudGl0eUh1YiIsInB1YmxpY0tleSI6IiNrZXkxIiwic2VydmljZUVuZHBvaW50Ijp7IkBjb250ZXh0Ijoic2NoZW1hLmlkZW50aXR5LmZvdW5kYXRpb24vaHViIiwiQHR5cGUiOiJVc2VyU2VydmljZUVuZHBvaW50IiwiaW5zdGFuY2VzIjpbImRpZDpiYXI6NDU2IiwiZGlkOnphejo3ODkiXX19XX0",
  "signature": "mAJp4ZHwY5UMA05OEKvoZreRo0XrYe77s3RLyGKArG85IoBULs4cLDBtdpOToCtSZhPvCC2xOUXMGyGXDmmEHg"
}]

[csuwildcat]

@kdenhartog what integrity/proof are you imagining be sent back? The deltas and chain data refs used to compile the state?

[kdenhartog]

yeah that's what I had in mind. The initial payload and deltas is what I originally had in mind. chain data refs are probably useful as well, but I'm not sure how it should be structured in with the deltas to show which chain data refs are connected to the payload/deltas.

[csuwildcat]

@kdenhartog without at least running a light Sidetree node that stores all the anchor files, the only assurance you'd gain in a chain inclusion proof for op deltas is that whatever delta trail a node responded with was indeed present in the target chain, but there are many attacks possible - for example:

Say Alice has performed 5 ops against her DID. The last op was to remove a key she believed could have fallen into someone else's hands. A node could simply resolve the first 4 of her ops and omit the last one, and if all you had was proof of chain inclusion, you'd never realize it was a 'fake tip' of her total state. You must run a light node to avoid such attacks, or, for a lesser security assurance, query a larger randomized subset of nodes to probabilistically increase the chances you receive the correct current state.

[kdenhartog]

Hmm that's a good point. I'm wondering if we may be able to change the structure of the protocol to make this possible. I'll have to think about this more though.

[csuwildcat]

Hmm that's a good point. I'm wondering if we may be able to change the structure of the protocol to make this possible. I'll have to think about this more though.

If you can, I'd be thrilled, but after thinking about it really hard for a long time, I got to a point where I feel like it is in the same underlying problem-space as a formally validated solution to fraud proofs.

[thehenrytsai]

Implemented.